idnits 2.17.1 draft-ietf-pkix-sha224-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2004) is 7319 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'SHA2' -- Obsolete informational reference (is this intentional?): RFC 3369 (ref. 'CMS') (Obsoleted by RFC 3852) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley 3 Internet Draft Vigil Security 4 Expires in six months March 2004 6 A 224-bit One-way Hash Function: SHA-224 8 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026. Internet-Drafts are 14 working documents of the Internet Engineering Task Force (IETF), its 15 areas, and its working groups. Note that other groups may also 16 distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Drafts Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document specifies a 224-bit one-way hash function, called 32 SHA-224. A SHA-224 is based on SHA-256, but it uses an different 33 initial value and the result is truncated to 224 bits. 35 1 Introduction 37 This document specifies a 224-bit one-way hash function, called 38 SHA-224. The National Institute of Standards and Technology (NIST) 39 announced on February 28, 2004 the standard FIPS 180-2 Change Notice, 40 which specifies the SHA-224 one-way hash function. One-way hash 41 functions are also known as message digests. SHA-224 is based on 42 SHA-256, the 256-bit one-way hash function already specified by NIST 43 [SHA2]. Computation of a SHA-224 hash value is two steps. First, 44 the SHA-256 hash value is computed, except that a different initial 45 value is used. Second, the resulting 256-bit hash value is truncated 46 to 224 bits. 48 NIST is developing guidance on cryptographic key management, and NIST 49 recently published a draft for comment [NISTGUIDE]. Five security 50 levels are discussed in the guidance: 80, 112, 128, 192, and 256 bits 51 of security. One-way hash functions are available for all of these 52 levels except one. SHA-224 fills this void. SHA-224 is a one-way 53 hash function that provides 112 bits of security, which is the 54 generally accepted strength of Triple-DES [3DES]. 56 1.1 Usage Considerations 58 Since SHA-224 is based on SHA-256, roughly the same amount of effort 59 is consumed to compute a SHA-224 or a SHA-256 digest message digest 60 value. Even though SHA-224 and SHA-256 have roughly equivalent 61 computational complexity, SHA-224 is an appropriate choice for a one- 62 way hash function that provides 112 bits of security. The use of a 63 different initial value ensures that a truncated SHA-256 message 64 digest value cannot be mistaken for a SHA-224 message digest value 65 computed on the same data. 67 Some usage environments are sensitive to every octet that is 68 transmitted. In these cases, the smaller (by 4 octets) message 69 digest value provided by SHA-224 is important. 71 These observations lead to the following guidance: 73 * When selecting a suite of cryptographic algorithms that all offer 74 112 bits of security strength, SHA-224 is an appropriate choice 75 for one-way hash function. 77 * When terseness is not a selection criteria, the use of SHA-256 as 78 a preferred alternative to SHA-224. 80 1.2 Terminology 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [STDWORDS]. 86 2 SHA-224 Description 88 SHA-224 may be used to compute a one-way hash value on a message 89 whose length less than 2^64 bits. 91 SHA-224 makes use of SHA-256 [SHA2]. To compute a one-way hash 92 value, SHA-256 uses a message schedule of sixty-four 32-bit words, 93 eight 32-bit working variables, and produces a hash value of eight 94 32-bit words. 96 The function is defined in the exact same manner as SHA-256, with the 97 following two exceptions: 99 First, for SHA-224, the initial hash value of the eight 32-bit 100 working variables, collectively called H, shall consist of the 101 following eight 32-bit words (in hex): 103 H_0 = c1059ed8 H_4 = ffc00b31 104 H_1 = 367cd507 H_5 = 68581511 105 H_2 = 3070dd17 H_6 = 64f98fa7 106 H_3 = f70e5939 H_7 = befa4fa4 108 Second, SHA-224 simply makes use of the first seven 32-bit words 109 in the SHA-256 result, discarding the remaining 32-bit word in the 110 SHA-256 result. That is, the final value of H is used as follows, 111 where || denotes concatenation: 113 H_0 || H_1 || H_2 || H_3 || H_4 || H_5 || H_6 115 3 Test Vectors 117 This section includes three test vectors. These test vectors can be 118 used to test implementations of SHA-224. 120 3.1 Test Vector #1 122 Let the message to be hashed be the 24-bit ASCII string "abc", which 123 is equivalent to the following binary string: 125 01100001 01100010 01100011 127 The SHA-224 hash value (in hex): 129 23097d22 3405d822 8642a477 bda255b3 2aadbce4 bda0b3f7 e36c9da7 131 3.2 Test Vector #2 133 Let the message to be hashed be the 448-bit ASCII string 134 "abcdbcdecdefdefgefghfghighijhijkijkljklmklmnlmnomnopnopq". 136 The SHA-224 hash value is (in hex): 138 75388b16 512776cc 5dba5da1 fd890150 b0c6455c b4f58b19 52522525 140 3.3 Test Vector #3 142 Let the message to be hashed be the binary-coded form of the ASCII 143 string which consists of 1,000,000 repetitions of the character "a". 145 The SHA-224 hash value is (in hex): 147 20794655 980c91d8 bbb4c1ea 97618a4b f03f4258 1948b2ee 4ee7ad67 149 4 Object Identifier 151 NIST has assigned an ASN.1 [X.208-88, X.209-88] object identifier for 152 SHA-224. Some protocols use object identifiers to name one-way hash 153 functions. One example is CMS [CMS]. Implementations of such 154 protocols that make use of SHA-224 MUST use the following object 155 identifier. 157 id-sha224 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) 158 country(16) us(840) organization(1) gov(101) 159 csor(3) nistalgorithm(4) hashalgs(2) sha224(4) } 161 5 Security Considerations 163 One-way hash functions are typically used with other cryptographic 164 algorithms, such as digital signature algorithms and keyed-hash 165 message authentication codes, or in the generation of random values. 166 When a one-way hash function is used in conjunction with another 167 algorithm, there may be requirements specified elsewhere that require 168 the use of a one-way hash function with a certain number of bits of 169 security. For example, if a message is being signed with a digital 170 signature algorithm that provides 128 bits of security, then that 171 signature algorithm may require the use of a one-way hash algorithm 172 that also provides the same number of bits of security. SHA-224 is 173 intended to provide 112 bits of security, which is the generally 174 accepted strength of Triple-DES [3DES]. 176 This document is intended to provide the SHA-224 specification to the 177 Internet community. No independent assertion of the security of this 178 one-way hash function by the author for any particular use is 179 intended. However, as long as SHA-256 provides the expected 180 security, SHA-224 will also provide its expected level of security. 182 6 Normative References 184 [SHA2] Federal Information Processing Standards Publication 185 (FIPS PUB) 180-2, Secure Hash Standard, 1 August 2002. 187 [STDWORDS] Bradner, S., "Key Words for Use in RFCs to Indicate 188 Requirement Levels", BCP 14, RFC 2119, March 1997. 190 7 Informative References 192 [3DES] American National Standards Institute. ANSI X9.52-1998, 193 Triple Data Encryption Algorithm Modes of Operation. 194 1998. 196 [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", 197 RFC 3369, August 2002. 199 [NISTGUIDE] National Institute of Standards and Technology. Second 200 Draft: "Key Management Guideline, Part 1: General 201 Guidance." June 2002. 202 [http://csrc.nist.gov/encryption/kms/guideline-1.pdf] 204 [X.208-88] CCITT Recommendation X.208: Specification of Abstract 205 Syntax Notation One (ASN.1). 1988. 207 [X.209-88] CCITT Recommendation X.209: Specification of Basic 208 Encoding Rules for Abstract Syntax Notation One (ASN.1). 209 1988. 211 8 Acknowledgment 213 Many thanks to Jim Schaad for generating the test vectors. A second 214 implementation by Brian Gladman was used to confirm that the test 215 vectors are correct. 217 9 Intellectual Property Rights 219 The IETF takes no position regarding the validity or scope of any 220 intellectual property or other rights that might be claimed to 221 pertain to the implementation or use of the technology described in 222 this document or the extent to which any license under such rights 223 might or might not be available; neither does it represent that it 224 has made any effort to identify any such rights. Information on the 225 IETF's procedures with respect to rights in standards-track and 226 standards-related documentation can be found in BCP-11. Copies of 227 claims of rights made available for publication and any assurances of 228 licenses to be made available, or the result of an attempt made to 229 obtain a general license or permission for the use of such 230 proprietary rights by implementors or users of this specification can 231 be obtained from the IETF Secretariat. 233 10 Author's Address 235 Russell Housley 236 Vigil Security, LLC 237 918 Spring Knoll Drive 238 Herndon, VA 20170 239 USA 240 housley@vigilsec.com 242 Full Copyright Statement 244 Copyright (C) The Internet Society (2004). All Rights Reserved. 246 This document and translations of it may be copied and furnished to 247 others, and derivative works that comment on or otherwise explain it 248 or assist in its implementation may be prepared, copied, published 249 and distributed, in whole or in part, without restriction of any 250 kind, provided that the above copyright notice and this paragraph are 251 included on all such copies and derivative works. In addition, the 252 ASN.1 modules presented in Appendices A and B may be used in whole or 253 in part without inclusion of the copyright notice. However, this 254 document itself may not be modified in any way, such as by removing 255 the copyright notice or references to the Internet Society or other 256 Internet organizations, except as needed for the purpose of 257 developing Internet standards in which case the procedures for 258 copyrights defined in the Internet Standards process shall be 259 followed, or as required to translate it into languages other than 260 English. 262 The limited permissions granted above are perpetual and will not be 263 revoked by the Internet Society or its successors or assigns. This 264 document and the information contained herein is provided on an "AS 265 IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK 266 FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT 267 LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL 268 NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY 269 OR FITNESS FOR A PARTICULAR PURPOSE.