Errata Search
RFC Number:		Errata ID:
Source of RFC		Status:	All/Any Verified+Reported Verified Reported Held for Document Update Rejected
Area Acronym:	All/Any app art gen int ops rai rtg sec tsv wit	Type:	All/Any Editorial Technical
WG Acronym:		Submitter Name:
Other:	All/Any IAB INDEPENDENT IRTF Legacy Editorial	Date Submitted:
Summary Table Full Records

RFC 4634, "US Secure Hash Algorithms (SHA and HMAC-SHA)", July 2006

Note: This RFC has been obsoleted by RFC 6234

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

---

Errata ID: 2441
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alfred Hoenes
Date Reported: 2006-08-13
Held for Document Update by: Sean Turner
Date Held: 2010-08-06

Section 8.2.3 says:

Similar to item (9), (16), (17), (22), (29), and (30) above, the
Description of SHA384_512ResultN contains improper wording.
Additionally, counting 48/64 elements as ranging from the "0th" up to
the "48th/64nd" is unpleasant and wrong -- that erroneously indicates
49/65 elements (octets) !

On page 65/66, the RFC says:

 * Description:
 *   This helper function will return the 384-bit or 512-bit message
<< page break >>
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE: The first octet of hash is stored in the 0th element,
 *      the last octet of hash in the 48th/64th element.

For correctness, it should say:

 * Description:
 *   This helper function will return the 384-bit or 512-bit message
<< page break >>
 *   digest into the Message_Digest array provided by the caller.
 *   NOTE:
 *    The first octet of the hash is stored in the element with index 0,
 *    the last octet of the hash in the element with index 47/63.

Report New Errata