Update: Just use their RSS feeds. They have updated them to include full details rendering my own versions mute.

One of the resources I use to monitor for current cryptography papers is the Cryptology ePrint Archive, a routinely updated repository of all cryptography papers. Recently the Archive setup their own RSS feeds. Their feed provides a link to the article summaries. For me this isn’t enough and for a while I’ve had my own bot building an RSS feed listing the latest additions to the archive including their full summary inside the feed itself, not just a link to it. It was too buggy to link publicly so last night I fixed what should be the last of the problems to providing a stable feed. I have a feed for just newly published articles and another for all articles new or updated.

Incomplete: Need to discuss how the author discovered attacks. Need to check my description using the detailed equations provided. I must illustrate the attack methods.

The interest in this thesis is due to its reference in Heard Hash Functions and many other papers relating to hash algorithms. In Chapter 5 a fixed point attack against hash algorithms is discussed. Methods are given for overcoming the appended message length specified in Merkle-Damgård (cache) constructed hash functions.

What is a Fixed Point Attack?
A Fixed Point Attack involves finding a random block whose properties allow the attacker to insert the block into the original message without changing the final hash. As a result two different messages are created with the same hash (the original message and the original+the special block). To produce this special block first make note of all the internal hash states produced after each block is compressed (see: SHA-1 Illustrated). Next generate random blocks (Xi) until you find one that meets two properties:

1. The hash state before compression of block Xi is the same as the hash state returned after compression.
2. The hash state of Xi equals one of the internal hash states of the original message.

After finding such a block it can be inserted into the message directly after the message block whose internal hash state it matched.

Overcoming Message Length
MD5, MD4 and SHA use Merkle-Damgård construction (cache) which specifies that the length of the entire message be appended to it. Therefor, a simple Fixed Point Attack will not do because the message length will change when the special block is inserted. This intern changes the hash of the last block thereby changing the final hash returned. The paper gives 3 methods to overcome this.

1. The length is a 64 bit integer so add the special block 2^64 times, in affect causing the number to loop. This does not work on SHA because SHA does not cover messages greater than 2^64 bits.

2. Look for any two internal hash states in the message that equal each other. If you are lucky enough to have such a message you can delete all the blocks between the two and then expand the message back to the original size using the Fixed Point Attack.

3. Run a Fixed Point Attack and make note of the place in the original message where you can insert the special block. Now, remember that the block compression function adds the resulting hash state to the previous hash state. That means that compression is a function of the current block and the previous blocks hash state. With that understood, we want to find another random block that means the following two requirements:

• The hash state before compression of block Xj is set to the first hash state of the original message.
• The resulting hash state of Xj equals one of the internal hash states of the original message which is less than the hash state matched by the Fixed Point attack.

You’ll notice that this block uses the same method as the Fixed Point only it initializes the incoming hash state to the compression function to be that of the first hash state of the message.

Now we can insert the Xj into the message directly after the message block whose internal hash state it matched. Since the compression of Xj takes the first hash state of the message we delete all the blocks up until that point, effectively making Xj the first block and reducing the size of the message. Now the Fixed Point block Xi can be inserted into the message directly after the message block whose internal hash state it matched and can be repeated to bring the message back to it’s original size.

This chapter also discusses how the attack was found as well as possible solutions. which I still need to cover.

References
References I must find:

• [PvO95] Bart Preneel and Paul C. van Oorschot. MDx-MAC and building fast MACs from hash functions. In Don Coppersmith, editor, Proc. CRYPTO 95, pages 1–14. Springer, 1995. Lecture Notes in Computer Science No. 963.

To find the attacks the author used Binary Decision Diagrams to look at the logical structure of MD5,MD5,SHA-1. References I must find:

• [Bry92] Randal E. Bryant. Symbolic boolean manipulation with ordered binary decision diagrams. ACM Computing Surveys, 24(3):293–318, September 1992.
• [Hu97] Alan J. Hu. Formal hardware verification with BDDs: An introduction. In IEEE Pacific Rim Conference on Communications, Computers, and Signal Processing, pages 677–682, 1997.

Incomplete: must create detailed diagram for compression functions.

The following simplifies the specification of SHA-1 in an easy to digest form. First we will cover the general structure of the algorithm. Detail of the expansion and compression routines are covered separately.

First we start with a message. The message is padded and the length of the message is added to the end. It is then split into blocks of 512 bits (Figure 2).

(Figure 2)

The blocks are then processed one at a time. Each block must be expanded and compressed. The value after each compression is added to a 160bit buffer called the current hash state. After the last block is processed the current hash state is returned as the final hash. A overview of this procedure can be seen in Figure 3.

(Figure 3)

Let’s look more closely at the expansion and compression functions. For expansion each 512 bit message block is separated into chunks of 32 bits. As you can see in Figure 3 these 16 chunks are then used to create 64 more chunks for a total of 80. Details of how this is done are described later.

(Figure 4)

Now all 80 of these chunks are compressed into a 160 bit value which is added to the current hash state (Figure 5):

(Figure 5)

Figure 5 shows one block being processed. The expansion and compression functions are repeated for each block with the return constantly being added to the current hash state buffer. Once all blocks have been processed it is this value that is returned as the hash of the message.

3 tasks were generalized above: How the message is prepared before processing, how exactly the block is expanded to 80 chunks (Figure 4) and how those chunks are compressed (Figure 5). It is not essential to understand them in detail but should you desire, here are the details.

Message Preparation

The message is prepared in 4 steps:

1. Append a single binary 1 bit to the message
2. Split into blocks of 512 bits each (Figure 2 above)
3. The last block must be equal to 448 so that we can append the message length (next step). If it is under pad with binary 0 bits until equal to 448. If over, pad until it is 512 bits and create an additional block of 448 binary 0 bits.
4. Append the length of the original message to the last block. Represent this length as a 64 bit integer (making the last block equal to 512 bits).

I should also mention that before we process any blocks we must initiate the hash state buffer. The buffer is actually 5 separate 32 bit integers:

• h0 = 67452301
• h1 = EFCDAB89
• h2 = 98BADCFE
• h3 = 10325476
• h4 = C3D2E1F0

Block expansion
Each 512 bit block is split further into 32 bit chunks (“words“) as seen in Figure 4. These 16 chunks are then expanded to a total of 80. The processes of expansion is a simple XOR of 4 values. For instance, the next chunk, chunk 17, is created by XOR’ing together chunk 17-3, 17-8, 17-14 and 17-16. For chunk 18 run the same processes but subtracting from 18 instead of 17. This continues until all 80 have been created. This can clearly be seen in the animation to the right. (If the animation is not playing reload the page.)

Block compression

This work is licensed under a Creative Commons Public Domain License and may be used however you wish.  For sources to Dia based diagrams, contact me.

Update 2006.02.11: clearer explanation of CTFP preimage resistance.

This is a very good introduction to what a hash algorithm is, what it is for and what collisions are all about. It does not cover specific details, only the general understanding. It’s a quick read so I’ll forgo summarizing the contents.

The article explains the common terms used in most papers that discuss collisions. These terms are used to classify the type of collision attacks possible and are necessary to understand when reading other papers:

• Collision resistance measures how difficult it is to create two inputs which produce any hash value which is the same for both inputs. In this scenario the attacker can control both inputs.
• Preimage resistance measures how difficult it is to create one input which matches the hash value of an unknown input. Here the attacker does not know the other input and is restricted by needing to create a specific hash value.
• Second preimage resistance measures how difficult it is to create one input which matches the hash value of a known input. Here the attacker can see both inputs but only controls one. Attacker is still restricted by having to create an input which matches the specific hash value of the other. However, knowing the input that produced the hash might be of assistance.

Both preimage and second preimage are similar in that the objective is to get one input to match a predefined hash which is not controlled by the attacker. Also, in the Herding Hash Functions by John Kelsey and Tadayoshi Kohno they that there is a 4rth resistance value:

• Chosen Target Forced Prefix preimage resistance measures how difficult it is to create a collision when the first input is known while the second input is not know yet. This is similar to preimage resistance except that here the attacker controls the first input and not the second. Well, almost. The attacker is permitted to append data to the second input. The attacker must determine the hash first using the first input and then “herd” the second input to the same hash. Herding is done by adding data to the second input to make it collide. Is a process that involves carefully predetermining the first input and using internal states from its hash generation in the appended data to the second.

The paper describes an attack that would allow an attacker to massage (“herd”) an object to a point where it matches a hash value chosen by the attacker prior. What appears to be an important restriction is that the hash value has to be defined by the attacker prior to attack. This is important because in most uses of hash algorithms the victim would be the one defining the hash, not the attacker. Hence, this attack will not help you construct a message that matches a password hash.

The steps required for the attack are:

1. Attacker runs a collision finding attack on a hash algorithm and creates an array of intermediate hash states. In the paper this array is referred to as the “diamond structure”. It is not clear to me how the size of this structure is determined but half of the intermediate hash states in this structure can be used in creating message blocks (next step) to be imposed on the victim object in order to allow the attacker to edit that object and still produce the same hash as the original.
2. After having the diamond structure made the attacker then runs an exhaustive search for a string which collides with one of the intermediate hash states in the structure. Once found the attacker can “construct a sequence of message blocks” in order to build the proper suffix which will be added to the original object and the attackers edited version.

Questions I have concerning the above process are:

• After finding a collision how does one build the intermediate hash states. For this I will need to read up more on current collision finding methods: Multicollisions in iterated has functions by Antoine Joux (need to find), Formal aspects of mobile code security by Richard Drews Dean (attached). Learning more about hash states in a few hash algorithms should also help.
• How is the size of the diamond structure determined?
• What is the relation of the message blocks (used to create the final suffix added to the two different objects that collide) and the intermediate hash states?
• Finally, how does the attacker determine which message blocks are to be used with the suffix, and what is the function for creating the suffix.

Perhaps some of the above questions can be answered with another read, if I can find the time. Also would like to find is “How to Swindle Rabin” by Gideon Yuval.

One example application mentioned is abusing trust in a manner similar to social engineering. A malicious programmer writing a piece of code for a project which manages the code trust based on hash values. The attacker first runs a computation for building a diamond like structure/list of hash values that are optimum for collision. They then write some legitimate unsuspecting code which hashes to one of the chosen values. An auditor reviews the code and enters it into the code repository. The attacker can now edit that code and add a small back door.

All in all this paper reminds me in some way of Dan Kaminsky’s exploit of the MD5 collision examples which he describes in his paper MD5 To Be Considered Harmful Someday (attached). He constructed files that included the example collision messages within and continued to produce MD5 collisions. The difference with the Hash herding described here is that the message used can look coherent and unsuspecting. The method differs from Dan’s in that hash herding uses the internal messages produced at different stages of the hash algorithm to give the attack the flexibility required to have greater control on the message.


]]> http://deadhacker.com/2006/02/01/herding-hash-functions/feed/ 3 cyphunk