问题描述
所以我一直在研究长度扩展攻击的概念，在研究过程中我注意到的一些事情对我来说不是很聪明。
1.研究论文解释了如何将某种类型的数据附加到末尾并生成新形成的数据。例如
所需的新数据：count=10&lat=37.351&user_id=1&long=-119.827&waffle=eggo&waffle=liege
（注意 2 个华夫饼）。我的问题是如果服务器端的解析器函数可以跟踪重复的属性，那么整个长度扩展攻击是否是无稽之谈？因为服务器会注意到重复的属性。与长度扩展攻击相比，用于检查任何重复项的正确解析器是否是一个好的解决方案？我知道 HMAC 方法和其他保护措施，但现在在这里专门讨论解析器。
2.Research 说只有易受攻击的数据是 H(key|message)。他们声称 H(message|key) 对攻击者不起作用，因为我们必须附加一个新密钥（我们显然不知道）。我的问题是为什么我们必须附加一个新密钥？我们在攻击 H(key|message) 时不这样做。为什么我们不能依赖这样一个事实，即我们将通过验证测试（我们将创建正确的哈希），并且如果解析器试图从中提取密钥，它将获取我们发送的块中的唯一密钥并从那里恢复？为什么我们必须发送 2 个密钥？为什么攻击 H(message|key) 不起作用？
解决方法
- 我的问题是，如果服务器端的解析器函数可以跟踪重复的属性，那么整个长度扩展攻击是否是无稽之谈？ 你在谈论一个写得很好的解析器。编写软件很难，编写正确的软件也很难。
在该示例中，您看到了一个被覆盖的属性。你能说一个好的解析器一定是最后一个还是第一个？规则是什么？可能有最后一个必须走的车站！这是一种可以应用或不应用的攻击。这取决于车站。如果你考虑到 length extension attack goes back to 1990s 的知识，那么找到一个适用于此的地方应该会让某人感到惊讶！。并且，在将近 20 年后，它于 2009 年被广泛应用于 Flickr API；
- 我的问题是为什么我们必须附加新密钥？我们在攻击 H(key|message) 时不这样做。为什么我们不能传递这样一个事实，即我们将通过验证测试（我们将创建正确的哈希）并且如果解析器试图从中提取密钥，它将获取我们发送的块中唯一的密钥并从那里恢复.为什么我们必须发送 2 个密钥？为什么攻击 H(message|key) 不起作用？
这次攻击是签名伪造。攻击者不知道密钥，但他们仍然可以伪造新的签名。新消息和签名 - 扩展哈希 - 被发送到服务器，然后服务器获取密钥并将其附加到消息中以执行规范验证，即；如果是，则签名有效。
解析器不提取密钥，它已经知道密钥。关键是你能不能确保数据真的被扩展了。 padding规则很简单，加上1，并填充很多个0，这样最后的64（128）就是长度编码（非常简化，比如SHA256的最终长度必须是512的倍数）。要查看内部是否有另一个填充，您必须检查每个块，然后您可以声称存在扩展攻击。是的，您可以这样做，但是，密码学的目标之一也是减少依赖性。如果我们可以创建一个更好的签名来消除检查，那么我们建议留下其他签名。这使软件开发人员能够轻松编写更安全的实现。
为什么攻击 H(message|key) 不起作用？
很简单，你得到扩展消息 message|extended 并发送扩展哈希
H(message|key|extended) 到服务器。然后服务器获取消息 message|extended 并附加键 message|extended|key 并将其散列 H(message|extended|key)，显然这不等于扩展的 H(message|key|extended)
请注意，SHA-512/256 等 SHA2 系列的修剪版本具有抵抗长度扩展攻击的能力。 SHA3 在设计上不受它的影响，并且支持简单的 KMAC 签名方案。 Blake2 也是免疫的，因为它采用 HAIFA 结构设计。