STUN MESSAGE-INTEGRITY 虚拟定义答案

【问题标题】：STUN MESSAGE-INTEGRITY dummy definitionSTUN MESSAGE-INTEGRITY 虚拟定义
【发布时间】：2021-04-08 23:23:36
【问题描述】：

在 RFC5389 MESSAGE-INTEGRITY 计算中包含自身，但带有虚拟内容
虚拟内容未定义
在不知道 dummy content 值的情况下如何验证 MESSAGE-INTEGRITY？
为什么 MESSAGE-INTEGRITY 计算会包含自身？
如果不包含自身，计算 MESSAGE-INTEGRITY 不是更快并且同样安全吗？

【问题讨论】：

标签： stun

【解决方案1】：

由于 MESSAGE-INTEGRITY 属性本身不是散列的一部分，因此您可以在最后 20 个字节中附加任何您想要的内容。只需将其替换为指向属性本身的所有字节的哈希即可。

算法基本上是这样的：

让L 为 STUN 消息字节流的原始大小。应该与 STUN 消息头中的 MESSAGE LENGTH 的值相同。
在 STUN 消息上附加一个 4 字节的标头，后跟 20 个空字节
调整 STUN 消息的 LENGTH 字段以考虑这 24 个新字节。
计算消息的第一个 L 字节的 HMAC/SHA1（除了您刚刚附加的 24 个字节之外的所有字节）。
将 20 个空字节替换为计算出的 20 个字节的哈希

正如在 cmets 中所讨论的，字节不必是空字节，它们可以是任何东西 - 因为它们不包含在哈希计算中。

在我的 Github 上有一个用于短期和长期凭证的 MESSAGE-INTEGRITY 实现：here 和 here

【讨论】：

您在哪里找到了 dummy content 的定义为零？
抱歉 - 我不得不重新阅读规范（和我的代码）并更改我的答案。基本上，您正在对 MESSAGE-INTEGRITY 属性本身之前和之前的所有内容进行哈希处理。因此，您可以从字面上使用您想要的任何内容，因为它不会被包含在哈希中。
诀窍是您获取原始 STUN 消息。通过向其添加 24 来破解 LENGTH 标头。然后 HMAC/SHA1 整个消息。然后在 MESSAGE-INTEGRITY 标头中附加哈希。
你说 MESSAGE-INTEGRITY 属性本身不是哈希的一部分，但 RFC5389 说 用作 HMAC 输入的文本是 STUN 消息，包括标题，直到并包括 MESSAGE-INTEGRITY 属性之前的属性
如果您的实现有效，那么这意味着 RFC5389 是错误的，并且 RFC5389 在顶部有一些内容是 Errata Exist