如何解决STUN MESSAGE-INTEGRITY 虚拟定义
在 RFC5389 MESSAGE-INTEGRITY 计算中包括自身但具有虚拟内容
虚拟内容未定义
如何在不知道虚拟内容值的情况下验证消息完整性？
为什么 MESSAGE-INTEGRITY 计算会包含自身？
如果不包括自身，计算 MESSAGE-INTEGRITY 是不是更快并且同样安全？
解决方法
由于 MESSAGE-INTEGRITY 属性本身不是散列的一部分，您可以在最后 20 个字节中附加任何您想要的内容。只需将其替换为指向属性本身的所有字节的哈希值即可。
算法基本上是这样的：
-
令
L为 STUN 消息字节流的原始大小。应该与 STUN 消息头中 MESSAGE LENGTH 的值相同。 -
在 STUN 消息上附加一个 4 字节的标头，后跟 20 个空字节
-
调整 STUN 消息的 LENGTH 字段以考虑这 24 个新字节。
-
计算消息的前
L个字节的 HMAC/SHA1（除了您刚刚附加的 24 个字节）。 -
用计算出的哈希值的 20 个字节替换 20 个空字节
正如评论中所讨论的，字节不必是空字节，它们可以是任何东西 - 因为它们不包含在哈希计算中。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
