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: 2438
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), and (22) above, the Description
of SHA384Result contains improper wording and unpleasent formatting.
Additionally, counting 48 elements as ranging from the "0th" up to the
"48th" is unpleasant and wrong -- indicating 49 elements (octets) !

Near the bottom of page 53, the RFC says:

 * Description:
 *   This function will return the 384-bit message
 *   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 element.

For correctness and consistency, and for improved readability,
it should say:

 * Description:
 *   This function will return the 384-bit message 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.

Report New Errata