HMAC 安全 - 基于 SHA-1 的 HMAC 的安全性是否会受到 SHA-1 碰撞攻击的影响？
基于SHA-1的HMAC的安全性是否会受到SHA-1碰撞攻击的影响？
Is the security of the HMAC based on SHA-1 affected by the collisions attacks on SHA-1?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
RFC 的安全部分详细描述了 HMAC 的安全含义。简而言之，确实需要非常强的攻击，HMAC的安全才会受到威胁；现有的针对 SHA-1 的碰撞攻击当然不构成这样的攻击。 HMAC 是专门为使攻击变得困难而设计的，普通的碰撞攻击通常是不够的：
我建议阅读整个部分；它更详细地说明了哪些攻击足以破坏 HMAC，以及需要付出多少努力。
The security implications of HMAC are described in detail in the security section of the RFC. In a nutshell, a very strong attack indeed is required before the security of the HMAC is threatened; the existing collision attacks on SHA-1 certainly don't constitute such. HMAC is specifically designed to make attacks difficult, and ordinary collision attacks won't generally suffice:
I recommend reading the whole section; it goes into more detail about exactly what attacks would suffice to break an HMAC, and just how much effort would be required.
请参阅此问题进行讨论同一主题。简而言之：碰撞攻击不会直接损害 HMAC。但碰撞攻击的存在意味着构建哈希函数的压缩函数不是“随机预言”，这使得 HMAC 安全证明失效。
See this question for a discussion on the same theme. In a nutshell: collision attacks do not directly harm HMAC. But the existence of collision attacks implies that the compression function on which the hash function is built is not a "random oracle", and this voids the HMAC security proof.
已知针对 HMAC 的最强攻击是基于以下频率：
哈希函数 H 的冲突（“生日攻击”）[PV,BCK2]，以及
对于最低限度合理的哈希函数来说是完全不切实际的。
举个例子，如果我们考虑像 MD5 这样的哈希函数，其中
输出长度等于 L=16 字节（128 位），攻击者需要
获取计算出的正确消息身份验证标签（使用
相同密钥 K！）在大约 264 个已知明文上。这会
要求在H下处理至少264个块，
在任何现实场景中都是不可能完成的任务（块长度为 64
字节，这在连续 1Gbps 链路中需要 250,000 年，并且
在此期间不改变秘密密钥K）。这次攻击
只有在碰撞中存在严重缺陷时才能成为现实
发现函数 H 的行为（例如发现碰撞
2**30 条消息后）。这样的发现将立即决定
替换功能 H（这种失败的影响将是
对于 H 的传统用法来说，要严格得多
数字签名、公钥证书等）。
注意：此攻击需要与常规攻击形成鲜明对比
对没有密钥的加密哈希函数的碰撞攻击
涉及 264 个离线并行 (!) 操作
足以找到碰撞。后者的攻击即将到来
可行性 [VW] *** 而对 HMAC 的生日攻击完全是
不切实际的。 （在上面的例子中，如果使用哈希函数
假设输出为 160 位，则 264 应替换为 280。）*
上述结构的正确实现，选择
随机（或加密伪随机）密钥，安全密钥
交换机制、密钥频繁刷新、保密性好
密钥的保护是安全的重要组成部分
HMAC提供的完整性验证机制。
The strongest attack known against HMAC is based on the frequency of
collisions for the hash function H ("birthday attack") [PV,BCK2], and
is totally impractical for minimally reasonable hash functions.
As an example, if we consider a hash function like MD5 where the
output length equals L=16 bytes (128 bits) the attacker needs to
acquire the correct message authentication tags computed (with the
same secret key K!) on about 264 known plaintexts. This would
require the processing of at least 264 blocks under H, an
impossible task in any realistic scenario (for a block length of 64
bytes this would take 250,000 years in a continuous 1Gbps link, and
without changing the secret key K during all this time). This attack
could become realistic only if serious flaws in the collision
behavior of the function H are discovered (e.g. collisions found
after 2**30 messages). Such a discovery would determine the immediate
replacement of the function H (the effects of such failure would be
far more severe for the traditional uses of H in the context of
digital signatures, public key certificates, etc.).
Note: this attack needs to be strongly contrasted with regular
collision attacks on cryptographic hash functions where no secret key
is involved and where 264 off-line parallelizable (!) operations
suffice to find collisions. The latter attack is approaching
feasibility [VW] ***while the birthday attack on HMAC is totally
impractical. (In the above examples, if one uses a hash function
with, say, 160 bit of output then 264 should be replaced by 280.)*
A correct implementation of the above construction, the choice of
random (or cryptographically pseudorandom) keys, a secure key
exchange mechanism, frequent key refreshments, and good secrecy
protection of keys are all essential ingredients for the security of
the integrity verification mechanism provided by HMAC.