RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

RFC 4226, "HOTP: An HMAC-Based One-Time Password Algorithm", December 2005

Source of RFC: IETF - NON WORKING GROUP
Area Assignment: sec

Errata ID: 6702
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Darian Miller
Date Reported: 2021-10-03

Section 5.2 says:

The Key (K), the Counter (C), and Data values are hashed high-order byte first.

It should say:

When hashing, the Key (K) value is provided in little-endian format while the Counter (C) value is in big-endian format.

Notes:

This byte reversal for the Counter (movingFactor) value is indeed demonstrated in the RFC's reference implementation code within Appendix C but this fact is not mentioned within RFC text body.

byte[] text = new byte[8];
for (int i = text.length - 1; i >= 0; i--) {
text[i] = (byte) (movingFactor & 0xff);
movingFactor >>= 8;
}


This specific issue is called out in a related wikipedia article:
https://en.wikipedia.org/wiki/HMAC-based_one-time_password: "counter must be big endian"


This can also be verified by looking at archived source of Google Authenticator on GitHub: https://github.com/google/google-authenticator/blob/51781910ae2bb1abf8ac51b290272f86f3651235/mobile/ios/Classes/OTPGenerator.m

Related code snippet:
(counter = NSSwapHostLongLongToBig(counter);)


FreeOTP also reverses the byte order of the counter
https://github.com/freeotp/freeotp-android/blob/eb2f12f33a38235433fd83e0ad3eb15affae871f/app/src/main/java/org/fedorahosted/freeotp/Token.java

code comment "// Encode counter in network byte order"
The code uses a Byte buffer which defaults to big_endian order.

Report New Errata



Advanced Search