Cryptography 这个RFC4226错了吗？

RFC的测试值规定：

Appendix D - HOTP Algorithm: Test Values

   The following test data uses the ASCII string
   "12345678901234567890" for the secret:

   Secret = 0x3132333435363738393031323334353637383930

   Table 1 details for each count, the intermediate HMAC value.

   Count    Hexadecimal HMAC-SHA-1(secret, count)
   0        cc93cf18508d94934c64b65d8ba7667fb7cde4b0
   1        75a48a19d4cbe100644e8ac1397eea747a2d33ab

因此，如果我尝试在ruby中获得0的HMAC，我会得到：

[20] pry(AuthyOTP)> secret_key = "12345678901234567890"
=> "12345678901234567890"
[22] pry(AuthyOTP)> OpenSSL::HMAC.hexdigest(digest, secret_key, "0")
=> "32a67f374525d32d0ce13e3db42b5b4a3f370cce"

我希望得到

cc93cf18508d94934c64b65d8ba7667fb7cde4b0

所以我用java编写了一个实现，得到了相同的结果：

Calculation OTP for movingFactor = 0
    2. Calculate Hash = 
      32a67f374525d32d0ce13e3db42b5b4a3f370cce

那么，当秘密是“123456789001234567890”时，“0”的十六进制SHA1-HMAC是什么呢？

RFC4226是正确的

---

您将字符串与字节混淆。假设您不计算“0”的hmac-sha1，而是计算从0开始的8字节整数的hmac-sha1。在java中，这将是

byte[]计数器={0,0,0,0,0,0}的hmac-sha1
你是对的……尽管这让人困惑。特别是因为其他语言上的HMAC函数是在字符串而不是字节上运行的。作为Java程序员，我不在乎其他语言是否不理解字符串和字节之间的区别。这些算法都是为字节定义的，显式执行编码要好得多，因为还没有定义标准编码。是的。我从来都不明白像PHP这样的语言是如何将字符串用于所有事情的