RFC Errata
Found 6 records.
Status: Verified (1)
RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997
Note: This RFC has been updated by RFC 6151
Source of RFC: ipsec (sec)
Errata ID: 501
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Gregory Ogonowski
Date Reported: 2005-06-23
Section 9 says:
MD5Update(&context, k_ipad, 64) /* start with inner pad */
It should say:
MD5Update(&context, k_ipad, 64); /* start with inner pad */
Notes:
Status: Held for Document Update (3)
RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997
Note: This RFC has been updated by RFC 6151
Source of RFC: ipsec (sec)
Errata ID: 2794
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Kasper Dupont
Date Reported: 2011-05-02
Held for Document Update by: Sean Turner
Section Appendix says:
key = "Jefe" data = "what do ya want for nothing?" data_len = 28 bytes digest = 0x750c783e6ab0b503eaa86e310a5db738
It should say:
key = "Jefe" key_len = 4 data = "what do ya want for nothing?" data_len = 28 bytes digest = 0x750c783e6ab0b503eaa86e310a5db738
Notes:
key_len was omitted from this test vector. The other test vectors specify both key_len and data_len.
Errata ID: 4809
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Erdem Memisyazici
Date Reported: 2016-09-23
Held for Document Update by: Stephen Farrell
Date Held: 2017-02-03
Section 2 says:
Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC.
It should say:
Applications MUST not use keys longer than B bytes.
Notes:
Using this approach creates an exploitable vulnerability where there are two known K instances, one the hashed key, and the other the key itself. As shown in the sample Java code below:
final byte[] keyBytes = KEY.getBytes();
final byte[] sha1 = HashUtil.sha1(keyBytes);
final String a = hmac_sha1(keyBytes, TEXT);
final String b = hmac_sha1(sha1, TEXT);
As demonstrated a equals b. To cite a real world vulnerability; for all keys longer than B, using password storage configurations which store the hash of the key for integrity checks, and store the key itself in a tamper proof device, there will exist plain text keys stored on both storage systems. Compromising a hash database should not reveal plain text secrets, which will only be true if an implementation first hashes the key and uses the resultant L byte string as the actual key to HMAC.
I suggest simply not allowing keys longer than B bytes, which will greatly improve the security of the standard.
Verifier notes: I started a thread [1] on the CFRG mailing list to discuss this. My reading of that thread leads me to conclude there there's consensus to not verify the erratum on the basis that the threat isn't that significant and a backwards incompatible change as would be required is not justified. However, if HMAC were to be updated in a manner that didn't require backwards compatibility then one would likely consider this. Hence marking this as "hold for document update"
Errata ID: 3694
Status: Held for Document Update
Type: Editorial
Publication Format(s) : TEXT
Reported By: Christopher Dearlove
Date Reported: 2013-08-14
Held for Document Update by: Sean Turner
Section References says:
"Keyed Hash Functions and Message Authentication"
It should say:
"Keying Hash Functions for Message Authentication"
Notes:
This is reference [BCK1]. It is also no longer directly available at the advertised URL, though can be found on that site. Alternatively it is easily available elsewhere, by searching with the quoted corrected title (which is why this erratum may help).
Status: Rejected (2)
RFC 2104, "HMAC: Keyed-Hashing for Message Authentication", February 1997
Note: This RFC has been updated by RFC 6151
Source of RFC: ipsec (sec)
Errata ID: 4459
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Bozhi ZHENG
Date Reported: 2015-08-27
Rejected by: Stephen Farrell
Date Rejected: 2015-08-27
Section Appendix says:
/* start out by storing key in pads */
bzero( k_ipad, sizeof k_ipad);
bzero( k_opad, sizeof k_opad);
bcopy( key, k_ipad, key_len);
bcopy( key, k_opad, key_len);
/* XOR key with ipad and opad values */
for (i=0; i<64; i++) {
k_ipad[i] ^= 0x36;
k_opad[i] ^= 0x5c;
}
It should say:
/* start out by storing key in pads */
bzero( k_ipad, sizeof k_ipad);
bzero( k_opad, sizeof k_opad);
bcopy( k_ipad, key, key_len);
bcopy( k_opad, key, key_len);
/* XOR key with ipad and opad values */
for (i=0; i<64; i++) {
k_ipad[i] ^= 0x36;
k_opad[i] ^= 0x5c;
}
Notes:
The ipad = the byte 0x36 repeated 64 times, opad = the type 0x5C repeated B times and then ipad and opad XOR K after it appended to 64 byptes.
--VERIFIER NOTES--
The net effect of the suggested change would be to zero the key
and make HMAC useless.
Errata ID: 8185
Status: Rejected
Type: Editorial
Publication Format(s) : TEXT
Reported By: ev
Date Reported: 2024-11-22
Rejected by: RFC Editor
Date Rejected: 2024-11-25
Section 5 says:
length t be not less than
It should say:
length to be not less than
Notes:
typo on what I assume should be 'to'
--VERIFIER NOTES--
We assume that "the output length t" refers to the t bits of output in the previous sentence:
"Applications of HMAC can choose to truncate the output of HMAC by outputting the t leftmost bits of the HMAC computation for some parameter t (namely, the computation is carried in the normal way as defined in section 2 above but the end result is truncated to t bits). We recommend that the output length t be not less than half the length of the hash output (to match the birthday attack bound) and not less than 80 bits (a suitable lower bound on the number of bits that need to be
predicted by an attacker)."