长度扩展攻击疑点
Length extension attack doubts
所以我一直在研究长度扩展攻击的概念，在研究过程中我注意到了一些对我来说不是很清楚的事情。
1.Research 论文正在解释如何将某种类型的数据附加到末尾并生成新形成的数据。例如
所需的新数据：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) 的攻击不起作用？
- My question is if a parser function on server side can track duplicate attributes, could then the entire length extension attack be a nonsense?
You are talking about a well-written parser. Writing software is hard and writing correct software is very hard.
在该示例中，您看到了一个被覆盖的属性。你能说一个好的解析器必须取最后一个或第一个吗？规则是什么？可以有最后一站必须走的站！那是可以应用或不应用的攻击。这取决于车站。如果你认为 length extension attack goes back to 1990s 的知识，那么找到一个适用于此的地方应该会让某人感到惊讶！。并且，在将近 20 年后，它在 2009 年被广泛应用于 Flickr API；
- My question is why would we have to append new key? We don't do it when we are attacking H(key|message). Why can't we relay on the fact that we will pass verification test (we would create correct hash) and that if parser tries to extract key from it, that it would take the only key in the block we send out and resume from there. Why would we have to send 2 keys? Why doesnt attack against H(message|key) work?
攻击是签名伪造。攻击者不知道密钥，但他们仍然可以伪造新的签名。新的消息和签名——扩展哈希——被发送到服务器，然后服务器获取密钥并将其附加到消息中以执行规范验证，即；如果是，则签名有效。
解析器没有提取密钥，它已经知道密钥。重点是你能不能确定数据是不是真的扩展了。填充规则很简单，加1，填充很多零，这样最后的64（128）就是长度编码（很简单，比如对于SHA256，最后的长度必须是512的倍数）。要查看内部是否有另一个填充，您必须检查每个块，然后您可以声称存在扩展攻击。是的，您可以这样做，但是，密码学的目标之一 也是减少依赖性。如果我们可以创建一个更好的签名来消除检查，那么我们建议留下其他签名。这使软件开发人员能够轻松编写更安全的实现。
Why doesn't attack against H(message|key) work?
简单，你得到扩展消息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 is also immune since it is designed with the HAIFA施工。
所以我一直在研究长度扩展攻击的概念，在研究过程中我注意到了一些对我来说不是很清楚的事情。
1.Research 论文正在解释如何将某种类型的数据附加到末尾并生成新形成的数据。例如
所需的新数据：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) 的攻击不起作用？
- My question is if a parser function on server side can track duplicate attributes, could then the entire length extension attack be a nonsense? You are talking about a well-written parser. Writing software is hard and writing correct software is very hard.
在该示例中，您看到了一个被覆盖的属性。你能说一个好的解析器必须取最后一个或第一个吗？规则是什么？可以有最后一站必须走的站！那是可以应用或不应用的攻击。这取决于车站。如果你认为 length extension attack goes back to 1990s 的知识，那么找到一个适用于此的地方应该会让某人感到惊讶！。并且，在将近 20 年后，它在 2009 年被广泛应用于 Flickr API；
- My question is why would we have to append new key? We don't do it when we are attacking H(key|message). Why can't we relay on the fact that we will pass verification test (we would create correct hash) and that if parser tries to extract key from it, that it would take the only key in the block we send out and resume from there. Why would we have to send 2 keys? Why doesnt attack against H(message|key) work?
攻击是签名伪造。攻击者不知道密钥，但他们仍然可以伪造新的签名。新的消息和签名——扩展哈希——被发送到服务器，然后服务器获取密钥并将其附加到消息中以执行规范验证，即；如果是，则签名有效。
解析器没有提取密钥，它已经知道密钥。重点是你能不能确定数据是不是真的扩展了。填充规则很简单，加1，填充很多零，这样最后的64（128）就是长度编码（很简单，比如对于SHA256，最后的长度必须是512的倍数）。要查看内部是否有另一个填充，您必须检查每个块，然后您可以声称存在扩展攻击。是的，您可以这样做，但是，密码学的目标之一 也是减少依赖性。如果我们可以创建一个更好的签名来消除检查，那么我们建议留下其他签名。这使软件开发人员能够轻松编写更安全的实现。
Why doesn't attack against H(message|key) work?
简单，你得到扩展消息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 is also immune since it is designed with the HAIFA施工。