Using AES to check file integrity, replacing MD5

Question

First of all: I know that AES is a block cipher, not a hash function. However, I was stuck with a microcontroller with very little RAM and flash memory, and AES-128 is already implemented on it and is used for its intended purpose - encryption.

Unfortunately, I will also have to implement a hash function to check the integrity of files on the same microcontroller. Given the limited resources, I was wondering if it is possible to use the existing AES algorithm instead of MD5 for hashing. One possibility to do this:

• Encrypt the first block of the file with a dummy key (for example, all zeros)
• Encrypt the next block using the previous encrypted block as a key
• Continue this until all data in the file has been processed.
• Use last encrypted block as a hash

In theory, I think this should work. If there is corrupted data in the file, this will lead to differences in all subsequent blocks.

Now the big question is: how well will this method work in terms of collisions? Or to put it another way: how well will the last "hash" spread?

Answer 1

It looks like you want to use AES-CMAC , an AES- based authentication algorithm.

Answer 2

Most emphatically yes, you can make a hash function from AES. In fact, a number of materials for the NIST SHA3 contest, which will solve the following hash function, approved by the US government, are exactly that .

The traditional hash function is a cascading compression function and it is easy to create compression functions from block ciphers . (Some people also went the other way and pulled the cypher block from SHA-2 for use independently.)

You can, of course, create the correct hash function from it, but if you need file integrity and therefore do not need it to have providence resistance, collision resistance or all other properties that cryptographic hashes have against attackers, then you may , even just put your AES chip in any chain mode that it has, load the file as a message and use the last block as a hash. (Just select fixed values ​​to use for key and IV. Nothing but my sleeve numbers , which look random but are probably not a good choice, like the first 128 bits after the decimal point in e and pi.)

Answer 3

Your proposed algorithm does not have a second preliminary image resistance (which also implies that it also does not have collision resistance), so it is not a cryptographically strong hash.

If I have a message P0 P1 P2 that hashes on H , then I can easily build a second message Q0 Q1 Q2 QX , which also hashes to H - arbitrarily choose Q0 Q1 Q2 , and then calculate QX to decrypt H using the corresponding key ( encryption Q2 ).