idnits 2.17.1 draft-dang-turner-sha-512-224-256-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 76 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. == Unrecognized Status in 'Intended status: ', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document date (May 22, 2013) is 3985 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. 'FIPS180' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186' ** Downref: Normative reference to an Informational RFC: RFC 2104 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual draft Q. Dang 3 Internet Draft NIST 4 Intended status: S. Turner 5 Expires: November 22, 2013 IECA 6 May 22, 2013 8 Recommended Usages of SHA-512/224, SHA-512/256 9 draft-dang-turner-sha-512-224-256-00.txt 11 Abstract 13 This document provides recommendations on the use of the secure hash 14 functions SHA-512/224 and SHA-512/256 specified in FIPS 180. SHA- 15 512/224 and SHA-512/256 are SHA-512-based and truncated to match the 16 output size of SHA-224 and SHA-256. On 64-bit platforms, the SHA-512- 17 truncated algorithms provide better performance than their comparably 18 sized SHA-224 and SHA-256 variants. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that other 27 groups may also distribute working documents as Internet-Drafts. 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/1id-abstracts.html. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on November 22, 2013. 42 Copyright Notice 44 Copyright (c) 2013 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction..................................................... 2 60 2. Conventions used in this document.................... ........... 3 61 3. Usage Recommendation for Digital Signatures with SHA-512/224 and 62 SHA-512/256...................................................... 3 63 4. SHA-512/224 and SHA-512/256 in HMAC ............................. 5 64 5. Security Considerations.......................................... 5 65 6. IANA Considerations.............................................. 5 66 7. Conclusions...................................................... 5 67 8. References ...................................................... 5 68 8.1. Normative References ......................................... 5 5 69 8.2. Informative References ....................................... 6 6 70 9. Acknowledgments.................................................. 6 71 10. Authors'Addresses............................................... 7 73 1. Introduction 75 NIST specified two hash algorithms, SHA-512/224 and SHA-512/256, in 76 the hash algorithms standard: FIPS 180 [FIPS180]. These two hash 77 algorithms have the same performance characteristics of SHA-512 78 since the only differences between them and SHA-512 are the initial 79 hash values (IVs) and the truncation step to reduce the 512-bit last 80 internal hash value to become 224 or 256-bit final hash value for 81 SHA-512/224 and SHA-512/256 respectively. 83 SHA-512 consumes roughly 10-45% fewer clock cycles per byte than 84 SHA-256 as shown from performance-comparison data for SHA-256 and 85 SHA-512 on many different 64-bit platforms by [SHA256]. This means 86 that SHA-512 runs roughly 10-80% faster than SHA-256 and SHA-224 87 on these 64-bit machines, which are becoming more prevalent. 88 Also, [512/256] provides performance comparison data for SHA-256 89 and SHA-512 on a specific 2010 Intel architecture, the Xeon X5670 90 processor. The data shows that SHA-512 consumes roughly 37% fewer 91 clock cycles per byte than SHA-256. Put another way, SHA-512 is 92 roughly 60% faster (more efficient) than SHA-256 on this machine. 94 This internet draft discusses the choices between using SHA-224 and 95 SHA-256 verses SHA-512/224 and SHA-512/256 in digital signature 96 applications and HMACs based on their performance advantages to each 97 other. 99 2. Conventions used in this document 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Usage Recommendation for Digital Signatures with SHA-512/224 and SHA- 106 512/256 108 Obviously, SHA-512/224 and SHA-512/256 may be substituted for SHA-224 109 and SHA-256 respectively in protocols and applications. 111 One of the common uses of hash functions is in digital signature 112 applications. There are three NIST-approved digital signature 113 algorithms defined in [FIPS186]: RSA, DSA and ECDSA. 115 When a 1024 or 2048-bit RSA digital signature algorithm is used, any 116 of the approved hash functions can be used since their biggest hash 117 value is only 512 bits (when SHA-512 is used). Different padding 118 methods have different required fields in the data block that is 119 signed by the RSA private key and the RSA moduli (1024 or 2048 bits). 120 The total size of these required fields and the hash value is not 121 greater than 1024 bits. Therefore, RSA digital signature applications 122 will not have any technical issues in deploying any of the approved 123 hash algorithms including SHA-512. Therefore, SHA-512/224 and SHA- 124 512/256 are not preferred over SHA-512 for RSA digital signature 125 applications. However, if a RSA digital signature application in a 126 system that is a 64-bit platform, SHA-512/224 and SHA-512/256 are 127 preferred over SHA-224 and SHA-256 respectively due to their 128 performance advantage over these latter two hash functions. 130 If communicating points in a protocol are mainly to be run on 64-bit 131 platforms, SHA-512/224 or SHA-512/256 should be used in 2048-bit RSA 132 digital signature application. It is important to note that 1024-bit 133 RSA digital signature generation is disallowed by NIST after 2013, 134 see SP 800-131A [131A] for more details. 136 If digital signature algorithm is negotiable in a protocol where 137 communicating points may be run on both 64-bit and smaller (32-bit 138 for example) platforms, RSA digital signature with either SHA-512/224 139 or SHA-512/256 should be an option if RSA digital signature algorithm 140 is supported. For example, if both ends of a communication run on 64- 141 bit platforms, they may want to use RSA with SHA-512/224 or SHA- 142 512/256. If both ends of the communication run on 32-(or smaller) bit 143 platforms (constrained environments), they may prefer to use RSA with 144 SHA-224 or SHA-256 instead. And, if one end runs on 64-bit platform 145 and the other end runs on a 32-(or smaller) bit platform, then it 146 depends on the situation for which what digital signature algorithm: 147 RSA with SHA-512/224 (or SHA-512/256) or RSA with SHA-224 (or SHA- 148 256) should be used (from negotiation). A server running on a 64-bit 149 machine that handles a lot of computation with many clients may 150 prefer to use RSA with SHA-512/224 or SHA-512/256, but a constrained 151 client may prefer to use RSA with SHA-224 or SHA-256 instead. 153 For DSA, there are two key pair sizes, which are NIST-approved: 154 (L=2048, N=224) and (L=3072, N=256) (the key pair size: (L = 1024, N 155 = 160) is not NIST-allowed to generate new digital signatures after 156 the end of 2013). In DSA digital signature generation process (see 157 FIPS 186 for details), if the hash value of the message is greater 158 than N (size of p), only N left-most bits of the hash value will be 159 used in the signing operation. Therefore, there is no security 160 reasons to deploy a hash function which produces hash output larger 161 than N (in bits) such as SHA-512. So, when getting performance 162 advantage from SHA-512/224 and SHA-512/256 over SHA-224 and SHA-256 163 on the platforms which are optimized for 64-bit operations is a good 164 thing, SHA-512/224 and SHA-512/256 should be used for (L=2048, N=224) 165 and (L=3072, N=256) DSA digital signature applications respectively. 167 If communicating points in a protocol are mainly to be run on 64-bit 168 platforms, SHA-512/224 and SHA-512/256 should be used in (L=2048, 169 N=224) and (L=3072, N=256) DSA digital signature applications 170 respectively. 172 If digital signature algorithm is negotiable in a protocol where 173 communicating points may be run on both 64-bit and smaller (32-bit 174 for example) platforms, DSA with SHA-512/224 or SHA-512/256 should be 175 an option if DSA digital signature algorithm is supported 177 ECDSA digital signature algorithms are specified in FIPS 186. Their 178 NIST-approved key sizes and hash functions are described in SPs 800- 179 57, part 1 [57] and 800-131A [131A]. After 2013, only curves with n 180 at least 224 bits are NIST-approved for digital signature generation. 181 In ECDSA, if the hash function produces the hash value bigger than 182 the size of n, then only the n left-most bits of the hash value are 183 used in computing and verifying the ECDSA digital signatures. 185 If communicating points in a protocol are mainly to be run on 64-bit 186 platforms, SHA-512/224 and SHA-512/256 should be used in 224 and 256- 187 bit ECDSA digital signature applications respectively. 189 If digital signature algorithm is negotiable in a protocol where 190 communicating points may be run on both 64-bit and smaller (32-bit 191 for example) platforms, 224 or 256-bit ECDSA with SHA-512/224 or SHA- 192 512/256 respectively should be an option if ECDSA digital signature 193 algorithm is supported. 195 4. SHA-512/224 and SHA-512/256 in HMAC 197 Besides being used in digital signature applications, hash functions 198 are also used in HMAC [RFC2104]. If an exact 224-bit or 256-bit HMAC 199 value is needed, SHA-512/224 and SHA-512/256 should be used instead 200 of truncating SHA-512's hash output. And, HMAC with SHA-512/224 or 201 SHA-512/256 is strongly recommended for protocols where communicating 202 parties are mainly to be run on 64-bit platforms over HMAC with SHA- 203 224 or SHA-256 respectively. 205 5. Security Considerations 207 Note that SHA-512/224 and SHA-512/256 provide 112 and 128 bits of 208 collision resistance for digital signatures. See NIST SP 800-107 209 [107] for more discussion about security of these two hash functions. 211 6. IANA Considerations 213 None. 215 7. Conclusions 217 Will be added later. 219 8. References 221 8.1. Normative References 223 [FIPS180] Federal Information Processing Standard (FIPS) 180-4, 224 Secure Hash Standard, National Institute of Standards 225 and Technology, March 2012. 227 [FIPS186] Federal Information Processing Standard (FIPS) 186-3, 228 Digital Signature Standard (DSS), National Institute of 229 Standards and Technology, June 2009. 231 [RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed- 232 Hashing for Message Authentication", RFC 2104, February 233 1997. 235 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 236 Requirement Levels", BCP 14, RFC 2119, March 1997. 238 8.2. Informative References 240 [SHA256] http://bench.cr.yp.to/xweb-hash/long-sha256.html 242 [512/256]Shay Gueron, Simon Johnson and Jesse Walker, SHA-512/256, 243 2011 Eighth International Conference on Information 244 Technology: New Generat 7. 246 [57] NIST Special Publication (SP) 800-57, Part 1, Recommendation 247 for Key Management: General,(Revision 3) July 2012. 249 [107] NIST SP 800-107, Revision 1, Recommendation for Applications 250 Using Approved Hash Algorithms, August 2012. 252 [131A] E. Barker and A. Roginsky, "Transitions: Recommendation for 253 Transitioning the Use of Cryptographic Algorithms and Key 254 Lengths", NIST Special Publication 800-131A, January 2011. 256 9. Acknowledgments 258 Will be added later. 260 10. Authors' Addresses 262 Quynh Dang 263 NIST 264 100 Bureau Drive, Stop 8930 265 Gaithersburg, MD 20899-8930 266 USA 268 EMail: quynh.dang@nist.gov 270 Sean Turner 271 IECA, Inc. 272 3057 Nutley Street, Suite 106 273 Fairfax, VA 22031 USA 275 EMail: turners@ieca.com