How strong is this hashing technique?

Question

1. Use AES/Rijndael or any symmetric encryption.

2. Encrypt the hidden value using itself as the key and a random IV.

3. Store the ciphertext + IV. Discard everything else.

4. To check the hash: try to decrypt using provided plaintext. If provided == decrypted, then it's OK.

5. Ignore ciphertext length problems.

Is this secure?

Knout

First, hashing != encryption and starting with a reversible encryption doesn't buy you anything. Secure hashing and encryption are both Very Hard Problems™ and you're much better off using an existing implementation of a proven algorithm. – Dandruff

Right. But here, encryption is used to hash. As far as I see, there's no possible way except brute-force to crack that one, plus the 'hash' is longer than the plaintext and therefore hash <==> text. Thx anyway (+1) – Glutathione

Why would you want to do this, when there are perfectly good hash algorithms you can use as-is? – Espouse

@Nick For fun. Of course I'm not gonna use this in a real world app. – Glutathione

@Stephen: I have to write some code for a a real-world embedded system that runs on a small microcontroller in which I already have a block-cipher implementation; I now need to add a hashing function to convert an arbitrary stream of data into 56 bits of hash. Simplicity is more important than speed. Something similar to this general approach would seem useful, though I'd do it differently (see my answer). – Rianna

Answer 1

As described, it has a problem in that it reveals information about the length of the data being hashed. That in itself would be some kind of weakness.

Secondly ... it is not clear that you would be able to check the hash. It would be necessary to store the randomly generated IV with the hash.

I was thinking about this while bicycling home, and one other possible issue came to mind. With a typical hashing scheme to store a password, it is best to run the hash a bunch of iterations (e.g., PBKDF2). This makes it much more expensive to run a brute force attack. One possibility to introduce that idea into your scheme might be to repeatedly loop over the encrypted data (e.g., feed back the encrypted block back into itself).

Tractarianism

For the length... I see your point, although if I restricted the plaintext length and padded it, this weakness would disappear. Are those two points the only ones? – Glutathione

@passcod: I thought of one other potential issue and possible solution and added it in an edit. It's an interesting question nonetheless. – Tractarianism

indeed. But implementing repeats are trivial. I was more looking at an argument that maybe using something to encrypt itself isn't secure... I'm not that deep into the inner workings of cryptography. – Glutathione

I am not able to answer the question from that standpoint. I have not done any cryptographic analysis of "real" algorithms like this. My current methodology is to read what the "experts" say to do and do that. There could be some weird mathematical correlation that could be exploited by encrypting a password with itself as opposed to hashing it. Based on that, my opinion would be to use a real hash function. My "gut" feel is that what you are proposing is okay ... but I would not recommend that you make any decisions based on my gut feeling of such a complex thing. – Tractarianism

Answer 2

There is an existing method of generating a hash or MAC using an block cipher like AES. It's called CBC-MAC. It's operation is pretty simple. Just encrypt the data to be hashed using AES in CBC mode and output the last block of the ciphertext, discarding all prior blocks of the ciphertext. The IV for CBC would normally be left as zero, and the AES key can be used to produce a MAC.

CBC-MAC does have some limitations. Do not encrypt and MAC your data using the same key and IV, or the MAC will simply be equal to the last block of the ciphertext. Also, the size of the hash/MAC is limited to the size of block cipher. Using AES with CBC-MAC produces a 128 bit MAC, and MACs are usually expected to be at least this size.

Something worth noting is that CBC-MAC is a very inefficient way to produce a MAC. A better way to go would be to use SHA2-256 or SHA2-512 in HMAC. In my recent tests, using SHA256 in HMAC produces a result approximately as fast as AES in CBC-MAC, and the HMAC in this case is twice as wide. However, new CPUs will be produced with hardware acceleration for AES, allowing AES in CBC-MAC mode to be used to very quickly produce a 128 bit MAC.

Gaylegayleen