RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 5 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 (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: 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.

Report New Errata



Advanced Search