SHA1 在 PBKDF2 中用作哈希函数仍然安全吗？
由于 SHA1 的加密分析取得了重大进展，因此应该会逐步淘汰它，取而代之的是 SHA2 (wikipedia) 。
然而，当用作 PBKDF2 中的底层哈希函数时，它基本上用作 PRNG。因此，使用 SHA1 作为 PBKDF2 的哈希值应该仍然是安全的，对吧？
As there have been significant advances in the cryptoanalysis of SHA1 it's supposed to be phased out in favor of SHA2 (wikipedia).
For use as underlying hash function in PBKDF2, however, it's basically used as a PRNG. As such it should be still secure to use SHA1 as hash for PBKDF2, right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
当然。如果您想生成更多密钥材料，SHA-256 或更大的值可能会更有效。
但 PBKDF2-HMAC-SHA1 没问题。标准 HMAC 的使用也没有受到影响，但同样，在这种情况下，较长的哈希值原则上更安全。
Sure. SHA-256, or larger, might be more efficient if you want to generate more key material.
But PBKDF2-HMAC-SHA1 is fine. Also standard HMAC use has not been compromised, but again, longer hashes are in principle more secure in that scenario.
对 SHA1 的攻击引起了很大的公众骚乱，使得构造与不同消息具有相同哈希值的消息成为可能。当然，对于每个散列函数来说，这总是可能的（原则上），因为散列函数的输出位少于输入位。然而，这通常不太可能是偶然发生的，故意这样做在计算上应该是不可行的。
从“确保消息完整性”的角度来看，这可以被视为一场灾难。
另一方面，对于生成随机数的目的来说，这完全没有关系。
The attacks on SHA1 which caused a lot of public turmoil make it possible to construct a message which has the same hash as a different message. This is of course always possible (in principle) for every hash function, since a hash function has fewer output bits than input bits. However, it is normally not likely to happen by accident, and doing it on purpose should be computationally not feasible.
From a "ensure message integrity" point of view, this can be seen as a disaster.
On the other hand, for the purpose of generating random numbers, this has absolutely no bearing.
当前已知的 SHA-1 弱点在 HMAC 中使用时不会对其安全性产生任何影响，在 PBKDF2 中使用时更是如此。就此而言，MD5 也可以（但 MD4 不行）。
然而，SHA-1 对公共关系不利：如果在 2011 年，您使用 SHA-1，那么您必须做好准备，必须证明该选择的合理性。另一方面，SHA-256 是一个很好的“默认函数”，没有人会质疑它。
PBKDF2 不存在性能问题（PBKDF2 包含一个“迭代计数”，旨在使其完全按照需要的速度运行），因此这里没有理由更喜欢 SHA-1 而不是 SHA-256。但是，如果您有一个使用 PBKDF2-with-SHA-1 的现有部署系统，则无需立即“修复”它。
None of the currently known weaknesses on SHA-1 has any impact on its security when used in HMAC, a fortiori when used in PBKDF2. For that matter, MD5 would be fine too (but not MD4).
However, SHA-1 is not good for public relations: if, in 2011, you use SHA-1, then you must prepare yourself to have to justify that choice. On the other hand, SHA-256 is a fine "default function" and nobody will question it.
There is no performance issue in PBKDF2 (PBKDF2 includes an "iteration count" meant to make it exactly as slow as needed) so there is very little reason to prefer SHA-1 over SHA-256 here. However, if you have an existing, deployed system which uses PBKDF2-with-SHA-1, then there is no immediate need to "fix" it.