How strong is this hashing technique?

1. Use AES/Rijndael or any symmetric encryption.

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

开发者_JAVA技巧

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?

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.

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).