RFC Errata

Errata Search

Source of RFC  
Summary Table Full Records

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: 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.


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"

Report New Errata

Advanced Search