idnits 2.17.1 draft-jivsov-openpgp-sha3-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 19, 2015) is 3174 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Workign Group A. Jivsov 3 Internet-Draft F5 Networks, Inc. 4 Intended status: Informational August 19, 2015 5 Expires: February 20, 2016 7 The use of Secure Hash Algorithm 3 in OpenPGP 8 draft-jivsov-openpgp-sha3-00 10 Abstract 12 This document presents the necessary information to implement the 13 SHA-3 hash algorithm with the OpenPGP format. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on February 20, 2016. 32 Copyright Notice 34 Copyright (c) 2015 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 2. Conventions used in this document . . . . . . . . . . . . . . 2 51 3. Overview of the hash algorithm use in OpenPGP . . . . . . . . 2 52 4. Supported SHA-3 algorithms . . . . . . . . . . . . . . . . . 3 53 5. Use with RSA digital signatures . . . . . . . . . . . . . . . 4 54 6. Interoperability concerns arising from an introduction of a 55 new hash algorithm . . . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 58 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 60 9.2. Informative References . . . . . . . . . . . . . . . . . 6 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 63 1. Introduction 65 The OpenPGP format [RFC4880] supports multiple hash algorithms. This 66 document provides the necessary information to use the Secure Hash 67 Algorithm-3 (SHA-3) hash algorithm with the OpenPGP format. 69 National Institute of Standards and Technology (NIST) selected 70 [Keccak] as the SHA-3 algorithm [SHA-3] for its elegant design, its 71 efficiency on various computing devices, high performance in hardware 72 implementations, and different internal structure that may provide 73 better defense against attacks on its predecessors from the SHA-1 and 74 SHA-2 family. 76 2. Conventions used in this document 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 3. Overview of the hash algorithm use in OpenPGP 84 Hash algorithm is used in [RFC4880] with digital signatures, with 85 modification detection code, and to calculate key fingerprints. Only 86 digital signatures allow algorithm agility and are most vulnerable to 87 various attacks on hash functions. The focus of this document is on 88 the use of SHA-3 hash with OpenPGP digital signatures. 90 The use of hash algorithm with digital signatures in OpenPGP falls 91 into two categories. The first one is the digital signatures over 92 messages, and another one is the certifications of the key material. 93 The latter area includes self-signatures, which convey key preference 94 information, among other tasks. The rest of key certifications are 95 third party key signatures. These categories will be considered 96 separately in more details in Section 6 for the impact on 97 interoperability. 99 4. Supported SHA-3 algorithms 101 SHA-3 specification [SHA-3] defines a single cryptographic hash 102 function that is parameterized to produce hash output of certain 103 sizes. This document refers to these instantiations of the same hash 104 algorithm as SHA-3 hash algorithms and treats them as different hash 105 algorithms with unique IDs 107 The SHA-3 algorithms SHA3-256, SHA3-384, and SHA3-512, which have the 108 output size of 256, 384, and 512 bits respectively, MAY be used as a 109 hash algorithm with digital signatures. 111 The input size to the hash algorithm in OpenPGP MUST be a multiple of 112 8 bits, in other words, the input is always represented as a sequence 113 of 8-bit octets. In more details, [SHA-3] provides domain separation 114 for different instantiations of [Keccak] by prefixing a message-to- 115 be-hashed M with two bits 01. M is what gets hashed with other hash 116 algorithms, such as SHA2-256, and MUST be a multiple of 8 bits. The 117 hashing of 01 bits can be integrated into the finalization stage of a 118 SHA-3 implementation. [SHA3IUF] may be useful in verifying the 119 correctness of the SHA-3 implementation. 121 An application MAY generate signatures with SHA3-256, SHA3-384, and 122 SHA3-512 hash algorithms. An application MUST implement signature 123 verification for 3 SHA-3 algorithms if it implements at least one of 124 the SHA-3 algorithms. The all-or-nothing requirement should be 125 feasible for the vast majority of implementations because it is 126 relatively easy to implement all SHA-3 algorithms with a single 127 unified implementation, such that the only variable that 128 distinguishes these algorithms is an integer representing the hash 129 output size (the capacity of the Keccak). In particular, there are 130 no special tables or magic constants that are specific to the hash 131 output size of the SHA-3 algorithms. 133 Applications MAY use any digital signature algorithm described in 134 [RFC4880] and Elliptic Curve DSA algorithm described in [RFC6637] 135 with SHA-3. 137 [SHA3IUF] 139 5. Use with RSA digital signatures 141 Section 5.2.2 of [RFC4880] describes the Version 3 Signature Packet 142 Format. One of allowed public key algorithms in that section is the 143 RSA digital signature algorithm. RSA signatures use the PKCS#1 144 encoding to format (cryptographically "pad") the output of the hash 145 algorithm. The padding includes the DER-encoded prefix that is fixed 146 for the given hash algorithm. While this prefix is a DER encoding of 147 an ASN.1 Object Identifier (OID), the length of the hash output, and 148 the supporting fields, it's possible to define the prefix as a fixed 149 sequence of octets. These prefixes are defined below. 151 Algorithm ASN.1 OID 152 ------------- ------------------------------------------------------- 153 SHA3-256 2.16.840.1.101.3.4.2.8 154 SHA3-384 2.16.840.1.101.3.4.2.9 155 SHA3-512 2.16.840.1.101.3.4.2.10 157 SHA-3 hash OIDs 159 The full DER-encoded hash prefixes are provided bellow. 161 Algorithm Full DER prefix 162 ------------- ------------------------------------------------------- 163 SHA3-256 30,31,30,0d, 06,09,60,86, 48,01,65,03, 04,02,08,05, 164 00,04,20 [32-byte hash] 165 SHA3-384 30,41,30,0d, 06,09,60,86, 48,01,65,03, 04,02,09,05, 166 00,04,30 [48-byte hash] 167 SHA3-512 30,51,30,0d, 06,09,60,86, 48,01,65,03, 04,02,0a,05, 168 00,04,40 [64-byte hash] 170 SHA-3 hash full DER prefixes 172 6. Interoperability concerns arising from an introduction of a new hash 173 algorithm 175 The use of a new hash algorithm in a public key certifications, 176 especially in self-signatures, can make the key unusable in the large 177 extent of the OpenPGP ecosystem. The impact of the use of the new 178 hash algorithm in a digital signature over a message is limited to 179 users who will be verifying this message. 181 Implementation MUST include SHA-3 algorithms in the Hash Algorithm 182 Preferences of the keys it generates when it updates the algorithm 183 preferences. This preference is described in the Section 13.3.2 of 184 [RFC4880]. 186 In cases when the message is both encrypted and signed, the 187 application knows the keys of the entities who will be performing 188 signature verification. The application SHOULD rely on Hash 189 Algorithm Preferences of the recipients' public keys to learn about 190 SHA-3 support. 192 Addition of the SHA-3 support will benefit from planning ahead. 194 The digital signature validation is dependent on wide support of the 195 selected hash algorithm by deployed OpenPGP implementations that will 196 be verifying the digital signature. In general, there is no method 197 in OpenPGP by which a party that issues a digital signature can be 198 certain about the support of a hash algorithm by other 199 implementations. 201 The safest method to mitigate these challenges is a phased deployment 202 of the new hash algorithm support in the application, as follows: 204 o Implement the hash algorithm, test it thoroughly. 206 o Enable its use with the digital signature algorithms and test 207 signature generation and verification, ideally, with multiple 208 implementations. Then disable the signature generation in the 209 production code (i.e. leave the "read support" only). 211 o Wait sufficiently long for the deployment of the applications that 212 can verify digital signatures with the new hash algorithm. 214 o Enable the generation of signatures with the new hash algorithm, 215 starting from the signatures over messages, later extending it to 216 certifications. 218 7. IANA Considerations 220 This document asks to allocate the consecutive hash algorithm IDs 221 from the Hash Algorithm ID range, defined in the Section 9.4 of 222 [RFC4880]. 224 The starting ID is not important, but the properties that the IDs are 225 sequential and in the given order are expected to simplify 226 implementation. 228 ID Algorithm Text Name 229 ------ --------------------------- ---------- 230 13 SHA-3 with 256 bit output "SHA3-256" 231 14 SHA-3 with 384 bit output "SHA3-384" 232 15 SHA-3 with 512 bit output "SHA3-512" 234 Table 1: SHA-3 hash IDs 236 8. Security Considerations 238 SHA-3 hash algorithms have different internal structure, informally 239 called "wide pipe" or "sponge" design, that may offer higher security 240 in the future over the strength of its SHA-2 predecessors with 241 identical output size, especially with digital signature 242 applications. 244 Table 2 from [SP800-57] SHOULD be used to determine the corresponding 245 strength of the public key algorithm for the given hash algorithm. 246 For example, the SHA-3 256 has equivalent security strength to the 247 NIST curve P-256 [RFC6637]. Refer to Table 4 in section A.1 [SHA-3] 248 for security strength of the SHA-3 algorithms. 250 9. References 252 9.1. Normative References 254 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 255 Requirement Levels", BCP 14, RFC 2119, 256 DOI 10.17487/RFC2119, March 1997, 257 . 259 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 260 Thayer, "OpenPGP Message Format", RFC 4880, 261 DOI 10.17487/RFC4880, November 2007, 262 . 264 [SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND 265 EXTENDABLE OUTPUT FUNCTIONS", August 2015, 266 . 268 9.2. Informative References 270 [Keccak] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, 271 "The Keccak sponge function family", 2012, 272 . 274 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 275 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 276 . 278 [SHA3IUF] Jivsov, A., "A single-file C implementation of SHA-3 with 279 IUF API", August 2015, . 282 [SP800-57] 283 NIST, "Recommendation for Key Management -- Part 1: 284 General (Revision 3)", July 2012, 285 . 287 Author's Address 289 Andrey Jivsov 290 F5 Networks, Inc. 292 Email: openpgp@brainhub.org