这种哈希技术有多强大？
使用 AES/Rijndael 或任何对称加密。
使用自身作为密钥和随机 IV 来加密隐藏值。
存储密文+IV。丢弃所有其他内容。
要检查哈希值：尝试使用提供的明文进行解密。如果提供 == 已解密，那么就可以了。
忽略密文长度问题。
这安全吗？
Use AES/Rijndael or any symmetric encryption.
Encrypt the hidden value using itself as the key and a random IV.
Store the ciphertext + IV. Discard everything else.
To check the hash: try to decrypt using provided plaintext. If provided == decrypted, then it's OK.
Ignore ciphertext length problems.
Is this secure?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
存在一种使用分组密码（如 AES）生成哈希或 MAC 的现有方法。它称为CBC-MAC。它的操作非常简单。只需使用 CBC 模式下的 AES 对要散列的数据进行加密，并输出密文的最后一块，丢弃密文的所有先前块。 CBC 的 IV 通常保留为零，而 AES 密钥可用于生成 MAC。
CBC-MAC 确实有一些限制。不要使用相同的密钥和 IV 对数据进行加密和 MAC，否则 MAC 将简单地等于密文的最后一个块。此外，散列/MAC 的大小受限于分组密码的大小。将 AES 与 CBC-MAC 结合使用会生成 128 位 MAC，并且通常预计 MAC 至少具有此大小。
值得注意的是，CBC-MAC 是一种非常低效的生成 MAC 的方法。更好的方法是在 HMAC 中使用 SHA2-256 或 SHA2-512。在我最近的测试中，在 HMAC 中使用 SHA256 产生的结果大约与 CBC-MAC 中的 AES 一样快，并且本例中的 HMAC 宽度是其两倍。然而，新的 CPU 将配备 AES 硬件加速功能，允许使用 CBC-MAC 模式下的 AES 非常快速地生成 128 位 MAC。
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.
正如所描述的，它有一个问题，因为它揭示了有关被散列的数据的长度的信息。这本身就是某种弱点。
其次......尚不清楚您是否能够检查哈希值。有必要将随机生成的 IV 与哈希一起存储。
我在骑自行车回家时思考这个问题，并想到了另一个可能的问题。使用典型的哈希方案来存储密码，最好运行哈希多次迭代（例如，PBKDF2）。这使得进行暴力攻击的成本变得更加昂贵。将这一想法引入到您的方案中的一种可能性可能是重复循环加密数据（例如，将加密块反馈回自身）。
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).