這是RFC 4226錯誤嗎？

RFC的測試值規定：這是RFC 4226錯誤嗎？

Appendix D - HOTP Algorithm: Test Values 

    The following test data uses the ASCII string 
    "123456789" 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

所以，如果我試圖讓HMAC 0在Ruby中，我得到：

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

我有望獲得cc93cf18508d94934c64b65d8ba7667fb7cde4b0

所以我用java寫了一個實現，並且我得到了相同的結果：

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

那麼祕密是「123456789」時，「0」的十六進制SHA1-HMAC是什麼？

來源

2012-02-26 daniel

RFC4226是正確的。

您正在將字符串與字節混淆。假設你不計算'0'的hmac-sha1，你應該計算一個從0開始的8字節整數的hmac-sha1。在java中，這將是hmac-sha1的byte [] counter = {0, 0, 0, 0, 0, 0, 0, 0};

來源

2012-02-26 21:34:31

你是對的......雖然這只是混亂。特別是因爲其他語言的HMAC功能對字符串操作，而不是字節操作。 – daniel 2012-02-26 21:50:43

作爲Java程序員，我不在乎其他語言是否不理解字符串和字節之間的差異。這些算法都是爲字節定義的，明確執行編碼要好得多 - 因爲還沒有定義標準編碼。 – 2012-02-27 02:05:43

是的。我從來沒有理解像PHP這樣的語言如何爲_everything_使用字符串 – SLaks 2012-02-27 03:44:09

這是RFC 4226錯誤嗎？

回答

相關問題