长度扩展攻击疑点

Question

所以我一直在研究这个长度扩展攻击的概念，在我的研究过程中我注意到的一些事情对我来说并不是很清楚。

1.研究论文正在解释如何将 append 某种类型的数据到底并制作新的数据。 例如

所需的新数据：count=10&lat=37.351&user_id=1&long=-119.827& waffle =eggo& waffle =liege

（注意 2 华夫饼）。 我的问题是，如果服务器端的解析器 function 可以跟踪重复属性，那么整个长度扩展攻击会是无稽之谈吗？ 因为服务器会注意到重复的属性。 用于检查任何重复项的适当解析器是否是与长度扩展攻击相比的良好解决方案？ 我知道 HMAC 方法和其他保护措施，但现在在这里专门讨论解析器。

2.Research 说只有易受攻击的数据是 H(key|message)。 他们声称 H(message|key) 对攻击者不起作用，因为我们必须 append 一个新密钥（我们显然不知道）。 我的问题是为什么我们必须给 append 一个新密钥？ 我们在攻击 H(key|message) 时不会这样做。 为什么我们不能相信我们将通过验证测试（我们将创建正确的哈希），并且如果解析器试图从中提取密钥，它将获取我们发送的块中的唯一密钥并从那里恢复？ 为什么我们必须发送 2 个密钥？ 为什么对 H(message|key) 的攻击不起作用？

Answer 1

1. 我的问题是，如果服务器端的解析器 function 可以跟踪重复属性，那么整个长度扩展攻击会是无稽之谈吗？ 您正在谈论一个编写良好的解析器。 编写软件很难，编写正确的软件非常困难。

在该示例中，您已经看到了一个被覆盖的属性。 你能说一个好的解析器必须取最后一个还是第一个？ 规则是什么？ 可能有最后一个必须乘坐的车站。 这是一种可以应用或不应用的攻击。 这取决于车站。 如果你认为长度扩展攻击的知识可以追溯到 1990 年代，那么找到一个适用于此的地方应该会让人感到惊讶。而且，它在 2009 年被广泛应用于 Flickr API； 近20年后；

• Flickr 的 API 签名伪造由 Thai Duong 和 Juliano Rizzo 于 2009 年 9 月 28 日发布。

2. 我的问题是为什么我们要 append 新密钥？ 我们在攻击 H(key|message) 时不会这样做。 为什么我们不能传递我们将通过验证测试（我们将创建正确的哈希）以及如果解析器试图从中提取密钥，它将获取我们发送的块中唯一的密钥并从那里恢复的事实. 为什么我们必须发送 2 个密钥？ 为什么对 H(message|key) 的攻击不起作用？

攻击是签名伪造。 攻击者不知道密钥，但他们仍然可以伪造新的签名。 新消息和签名 - 扩展 hash - 被发送到服务器，然后服务器获取密钥并将其附加到消息中以执行规范验证，即； 如果确实如此，则签名有效。

解析器不提取密钥，它已经知道密钥。 关键是你能确定数据是否真的被扩展了。 填充规则很简单，加1并填充许多零，这样最后64位（128）就是长度编码（非常简单，例如SHA256的最终长度必须是512的倍数）。 要查看内部是否有另一个填充，您必须检查每个块，然后您可以声称存在扩展攻击。 是的，您可以这样做，但是，密码学的目标之一也是减少依赖关系。 如果我们可以创建一个更好的签名来消除检查，那么我们建议留下其他人。 这使软件开发人员能够轻松编写更安全的实现。

为什么对 H(message|key) 的攻击不起作用？

很简单，您获取扩展消息message|extended并将扩展 hash H(message|key|extended)发送到服务器。 然后服务器获取消息message|extended并附加密钥message|extended|key并将其散列H(message|extended|key)显然这不等于扩展的H(message|key|extended)

请注意，SHA2 系列的修剪版本（如 SHA-512/256）具有抗长度扩展攻击的能力。 SHA3 在设计上不受它的影响，并且可以实现简单的 KMAC 签名方案。 Blake2也是免疫的，因为它采用HAIFA结构设计。