长度扩展攻击疑点

Question

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

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) 的攻击不起作用？

Answer 1

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

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

• Flickr's API Signature Forgery by Thai Duong and Juliano Rizzo Published on Sep. 28, 2009.

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

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

解析器不提取密钥，它已经知道密钥。关键是你能确定数据是否真的被扩展了。填充规则很简单，添加1并填充许多零，这样最后的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)

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