Этот RFC 4226 неверен?

Тестовые значения 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

Итак, если я попытаюсь получить HMAC для 0 в ruby, я получу:

[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

Итак, что такое шестнадцатеричный SHA1-HMAC «0», когда секрет «12345678901234567890»?


person daniel    schedule 26.02.2012    source источник


Ответы (1)


RFC4226 верен.

Вы путаете строки символов с байтами. Вы не должны вычислять hmac-sha1 для '0', вы должны вычислять hmac-sha1 для 8-байтового целого числа, которое начинается с 0. В java это будет hmac-sha1 для byte [] counter = {0, 0, 0, 0, 0, 0, 0, 0};

person President James K. Polk    schedule 26.02.2012
comment
Вы правы... хотя это просто сбивает с толку. Тем более, что функции HMAC на других языках работают со строками, а не с байтами. - person daniel; 27.02.2012
comment
Как Java-программист, меня не волнует, что другие языки не понимают разницы между строками и байтами. Все эти алгоритмы определены для байтов, гораздо лучше выполнять кодирование явно, потому что в любом случае не было определено стандартное кодирование. - person Maarten Bodewes; 27.02.2012
comment
Да. Я никогда не понимал, как такие языки, как PHP, могут использовать строки для всего. - person SLaks; 27.02.2012