NIST HMAC测试向量

Question

我正在搜索HMAC- the 256原语的测试向量，以验证实现的正确性。

我毫不犹豫地上了NIST网站，看看他们提供了什么。

在读取相应的文件(从HMAC.rsp到hmactestvectors.zip)时，我可以看到，与SHA256哈希函数关联的给定测试向量是以不同的键大小计算的：40、45、64和70 (以字节为单位)。

我对此感到有点惊讶，因为根据RFC 4868，使用的键应该由32字节组成：

虽然在HMAC中没有指定固定密钥长度，但该规范要求，当用作完整性/身份验证算法时，必须支持等于哈希函数输出长度的固定密钥长度，并且不能支持关联哈希函数输出长度以外的密钥长度。

另一方面，我读到：

但是，超过128位的密码密钥(对于HMAC之类的对称算法)并不真正增加安全性，因此实际上不需要使用完整的块长密钥。

(见HMAC密钥的要求是什么？)

这就是为什么这些测试向量让我困惑的原因：

1. 根据上面提到的RFC，使用的密钥应该是256-bit密钥。
2. 似乎大多数情况下，HMAC是用128-bit键计算的。

但是，NIST测试向量使用的密钥比输出长度更长(即256位，因为使用了SHA256 )。不过，根据RFC 4868的说法：

密钥长度小于输出长度会降低安全强度，而密钥长度大于输出长度不会显着增加安全强度。

那么，为什么NIST使用这些密钥大小来计算它们的测试向量呢？是因为HMAC算法主要是基于哈希函数的，而这个特性需要进行特殊的评估吗？还有本文件，它指定了验证HMAC实现所涉及的过程，但我没有看到任何证明选择密钥大小的理由。

要验证所讨论的实现，是否可以找到其他测试向量？我是否可以考虑，如果在RFC 4868中给出的那些被验证，那么它是很好的实现吗？

Answer 1

RFC4868不是HMAC，它实际上是RFC 2104。4868提到在IPSEC中使用HMAC，这就是为什么存在关键长度限制的原因。

可以在HMAC- The 256内部使用的最大长度键等于块大小、64字节或512位。这在密钥不是完全熵的情况下是有用的，例如由Diffie-Hellman密钥交换生成的共享秘密；512位的ECDH秘密具有大约256位的安全性。

如果键长度超过块长度，则必须首先对其进行散列以使其适合块，这就是70字节测试值的原因，以确保实现能够正确处理它。NIST向量中的其他长度等于块长度，2条任意较短的长度。如果一个实现可以处理所有4个测试值，那么通常可以假定它也可以处理一个32字节的密钥。

Answer 2

为什么选择这些东西并不是真正的答案，只有在NIST参与的人才能回答。不过，我不认为有太多需要测试的地方；在测试了几个向量之后，您将测试哈希函数，而不是HMAC。

快速测试显示了RFC 4868 2.7.2.1中的测试向量。SHA256身份验证测试向量必须正确，以防您真的需要32字节密钥的测试。不过，我认为这些都是正确的。如果您在实现中得到了相同的值，那么如果它们以某种方式关闭，就会有一些非常错误的地方。

如果您想真正测试您的实现，请尝试识别实现中的所有角落案例。然后用另一个经过良好测试的实现生成输入/输出值并进行比较。

例如，如果您有一个update函数，请确保没有任何字节超出界限读取的实例。使用1、2和3次update测试相同的向量，即尝试使用不同的块大小。