idnits 2.17.1 draft-jivsov-openpgp-sha3-01.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 3173 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-01 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 . . . . . . . . . . . . . . . 3 54 6. Interoperability concerns arising from an introduction of a 55 new hash algorithm . . . . . . . . . . . . . . . . . . . . . 4 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 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) with the OpenPGP format. 69 National Institute of Standards and Technology (NIST) selected 70 [Keccak] for its elegant design, its efficiency on various computing 71 devices, high performance in hardware implementations, and different 72 internal structure that may provide better defense against attacks on 73 its predecessors from the SHA-1 and SHA-2 family. [SHA-3] 74 specification is an instantiation of the [Keccak] algorithm. 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 key certifications includes self-signatures, which convey key 94 preference information, among other tasks. The rest of key 95 certifications are third party key signatures. These categories are 96 considered separately in Section 6 for their 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 a specific 103 size. 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 algorithm SHA3-256, SHA3-384, and SHA3-512, which has 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 more details, [SHA-3] provides domain separation for 113 different instantiations of [Keccak] by adding two bits 01 to a 114 message-to-be-hashed M. M is what gets hashed with other hash 115 algorithms, such as SHA2-256, and the length of M MUST be a multiple 116 of 8 bits. The hashing of 01 bits can be integrated into the 117 finalization stage of a SHA-3 implementation. A sample 118 implementation [SHA3IUF] demonstrates how to do this with 119 Init/Update/Finalize style of hashing API. 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 three SHA-3 algorithms if it implements at least one 124 of 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, as [SHA3IUF] demonstrates, where the only 128 variable that distinguishes these algorithms is an integer 129 representing the the capacity parameter of the Keccak. 131 Applications MAY use any digital signature algorithm described in 132 [RFC4880] and Elliptic Curve DSA algorithm described in [RFC6637] 133 with SHA-3. 135 5. Use with RSA digital signatures 137 Section 5.2.2 of [RFC4880] describes the Version 3 Signature Packet 138 Format. One of the allowed public key algorithms in that section is 139 the RSA digital signature algorithm. RSA signatures use the PKCS#1 140 encoding to format (cryptographically "pad") the output of the hash 141 algorithm. The padding includes the DER-encoded prefix that is fixed 142 for the given hash algorithm. While this prefix is a DER encoding of 143 an ASN.1 Object Identifier (OID), the length of the hash output, and 144 the supporting fields, it's possible to define the prefix as a fixed 145 sequence of octets. These prefixes are defined below. 147 Algorithm ASN.1 OID 148 ------------- ------------------------------------------------------- 149 SHA3-256 2.16.840.1.101.3.4.2.8 150 SHA3-384 2.16.840.1.101.3.4.2.9 151 SHA3-512 2.16.840.1.101.3.4.2.10 153 SHA-3 hash OIDs 155 The full DER-encoded hash prefixes are provided bellow. 157 Algorithm Full DER prefix 158 ------------- ------------------------------------------------------- 159 SHA3-256 30,31,30,0d, 06,09,60,86, 48,01,65,03, 04,02,08,05, 160 00,04,20 [32-octet hash] 161 SHA3-384 30,41,30,0d, 06,09,60,86, 48,01,65,03, 04,02,09,05, 162 00,04,30 [48-octet hash] 163 SHA3-512 30,51,30,0d, 06,09,60,86, 48,01,65,03, 04,02,0a,05, 164 00,04,40 [64-octet hash] 166 SHA-3 hash full DER prefixes 168 6. Interoperability concerns arising from an introduction of a new hash 169 algorithm 171 The use of a new hash algorithm in a public key certifications, 172 especially in self-signatures, can make the key unusable in the large 173 extent of the OpenPGP ecosystem. The impact of the use of the new 174 hash algorithm in a digital signature over a message is limited to 175 users who will be verifying this message. 177 Implementation MUST include SHA-3 algorithms in the Hash Algorithm 178 Preferences of the keys it generates when it updates the algorithm 179 preferences. This preference is described in the Section 13.3.2 of 180 [RFC4880]. 182 In cases when the message is both encrypted and signed, the 183 application knows the keys of the entities who will be performing 184 signature verification. The application SHOULD rely on Hash 185 Algorithm Preferences of the recipients' public keys to learn about 186 SHA-3 support. 188 Addition of the SHA-3 support will benefit from planning ahead. 190 The digital signature validation is dependent on wide support of the 191 selected hash algorithm by deployed OpenPGP implementations that will 192 be verifying the digital signature. In general, there is no method 193 in OpenPGP by which a party that issues a digital signature can be 194 certain about the support of a hash algorithm by other 195 implementations. 197 The safest method to mitigate these challenges is a phased deployment 198 of the new hash algorithm support in the application, as follows: 200 o Implement the hash algorithm, test it thoroughly. 202 o Enable its use with the digital signature algorithms and test 203 signature generation and verification, ideally, with multiple 204 implementations. Then disable the signature generation in the 205 released code (i.e. leave the "read support" only). 207 o Wait sufficiently long for the deployment of the applications that 208 can verify digital signatures with the new hash algorithm. 210 o Enable the generation of signatures with the new hash algorithm, 211 starting from the signatures over messages, later extending it to 212 certifications. 214 7. IANA Considerations 216 This document asks to allocate the consecutive hash algorithm IDs 217 from the Hash Algorithm ID range, defined in the Section 9.4 of 218 [RFC4880]. 220 The starting ID is not important, but the properties that the IDs are 221 sequential and in the given order are expected to simplify 222 implementation. 224 ID Algorithm Text Name 225 ------ --------------------------- ---------- 226 13 SHA-3 with 256 bit output "SHA3-256" 227 14 SHA-3 with 384 bit output "SHA3-384" 228 15 SHA-3 with 512 bit output "SHA3-512" 230 Table 1: SHA-3 hash IDs 232 8. Security Considerations 234 SHA-3 hash algorithms have different internal structure, informally 235 called "wide pipe" or "sponge" design, that may offer higher security 236 in the future over the strength of its SHA-2 predecessors with 237 identical output size, especially with digital signature 238 applications. 240 Table 2 from [SP800-57] SHOULD be used to determine the corresponding 241 strength of the public key algorithm for the given hash algorithm. 242 For example, the SHA-3 256 has equivalent security strength to the 243 NIST curve P-256 [RFC6637]. Refer to Table 4 in section A.1 [SHA-3] 244 for security strength of the SHA-3 algorithms. 246 9. References 248 9.1. Normative References 250 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 251 Requirement Levels", BCP 14, RFC 2119, 252 DOI 10.17487/RFC2119, March 1997, 253 . 255 [RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. 256 Thayer, "OpenPGP Message Format", RFC 4880, 257 DOI 10.17487/RFC4880, November 2007, 258 . 260 [SHA-3] NIST, "SHA-3 STANDARD: PERMUTATION-BASED HASH AND 261 EXTENDABLE OUTPUT FUNCTIONS", August 2015, 262 . 264 9.2. Informative References 266 [Keccak] Bertoni, G., Daemen, J., Peeters, M., and G. Van Assche, 267 "The Keccak sponge function family", 2012, 268 . 270 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 271 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 272 . 274 [SHA3IUF] Jivsov, A., "A single-file C implementation of SHA-3 with 275 IUF API", August 2015, . 278 [SP800-57] 279 NIST, "Recommendation for Key Management -- Part 1: 280 General (Revision 3)", July 2012, 281 . 283 Author's Address 285 Andrey Jivsov 286 F5 Networks, Inc. 288 Email: openpgp@brainhub.org