idnits 2.17.1 draft-barnes-cfrg-hpke-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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 18, 2019) is 1924 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MAEA10' is defined on line 341, but no explicit reference was found in the text == Outdated reference: A later version (-20) exists of draft-ietf-mls-protocol-03 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Barnes 3 Internet-Draft Cisco 4 Intended status: Informational K. Bhargavan 5 Expires: July 22, 2019 Inria 6 January 18, 2019 8 Hybrid Public Key Encryption 9 draft-barnes-cfrg-hpke-00 11 Abstract 13 This document describes a scheme for hybrid public-key encryption 14 (HPKE). This scheme provides authenticated public key encryption of 15 arbitrary-sized plaintexts for a recipient public key. HPKE works 16 for any Diffie-Hellman group and has a strong security proof. We 17 provide instantiations of the scheme using standard and efficient 18 primitives. 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). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on July 22, 2019. 37 Copyright Notice 39 Copyright (c) 2019 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Requirements Notation . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Properties . . . . . . . . . . . . . . . . . . . . . 3 57 4. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Hybrid Public Key Encryption . . . . . . . . . . . . . . . . 3 59 5.1. Key Encapsulation and Decapsulation . . . . . . . . . . . 4 60 5.2. Encryption and Decryption . . . . . . . . . . . . . . . . 5 61 6. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 6 62 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 9.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Appendix A. Possible TODOs . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 70 1. Introduction 72 Hybrid public-key encryption (HPKE) is a substantially more efficient 73 solution than traditional public key encryption techniques such as 74 those based on RSA or ElGamal. Encrypted messages convey a single 75 ciphertext and authentication tag alongside a short public key, which 76 may be further compressed. The key size and computational complexity 77 of elliptic curve cryptographic primitives for authenticated 78 encryption therefore make it compelling for a variety of use case. 79 This type of public key encryption has many applications in practice, 80 for example, in PGP [RFC6637] and in the developing Messaging Layer 81 Security protocol [I-D.ietf-mls-protocol]. 83 Currently, there are numerous competing and non-interoperable 84 standards and variants for hybrid encryption, including ANSI X9.63 85 [ANSI], IEEE 1363a [IEEE], ISO/IEC 18033-2 [ISO], and SECG SEC 1 86 [SECG]. Lack of a single standard makes selection and deployment of 87 a compatible, cross-platform and ecosystem solution difficult to 88 define. This document defines an HPKE scheme that provides a subset 89 of the functions provided by the collection of schemes above, but 90 specified with sufficient clarity that they can be interoperably 91 implemented and formally verified. 93 2. Requirements Notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in 98 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Security Properties 103 As a hybrid authentication encryption algorithm, we desire security 104 against (adaptive) chosen ciphertext attacks (IND-CCA2 secure). The 105 HPKE variants described in this document achieve this property under 106 the Random Oracle model assuming the gap Computational Diffie Hellman 107 (CDH) problem is hard [S01]. 109 4. Notation 111 The following terms are used throughout this document to describe the 112 operations, roles, and behaviors of HPKE: 114 o Initiator (I): Sender of an encrypted message. 116 o Responder (R): Receiver of an encrypted message. 118 o Ephemeral (E): A fresh random value meant for one-time use. 120 o "||": Concatenation of octet strings, i.e., "0x01 || 0x02 = 121 0x0102". 123 5. Hybrid Public Key Encryption 125 HPKE takes as input a recipient public key "pkR" and plaintext "pt" 126 and produces, as output, an ephemeral public key "pkE" and ciphertext 127 "ct". The ciphertext is encrypted such that only the owner of the 128 private key associated with "pkR" can decrypt the ciphertext "ct" to 129 recover the plaintext "pt". In the algorithms defined below, we also 130 allow the inclusion of Additional Authenticated Data (AAD) which is 131 authenticated, but not encrypted (as with an AEAD encryption 132 algorithm). 134 HPKE variants rely on the following primitives: 136 o A Diffie-Hellman scheme: 138 * GenerateKeyPair(): Generate an ephemeral key pair "(sk, pk)" 139 for the DH group in use 141 * DH(sk, pk): Perform a non-interactive DH exchange using the 142 private key sk and public key pk to produce a shared secret 144 * Marshal(pk): Produce a fixed-length octet string encoding the 145 public key "pk" 147 o A Key Derivation Function: 149 * Extract(salt, IKM): Extract a pseudorandom key of fixed length 150 from input keying material "IKM" and an optional octet string 151 "salt" 153 * Expand(PRK, info, L): Expand a pseudorandom key "PRK" using 154 optional string "info" into "L" bytes of output keying material 156 * Nh: The output size of the Extract function 158 o An AEAD encryption algorithm [RFC5116]: 160 * Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext 161 "pt" with associated data "aad" using secret key "key" and 162 nonce "nonce", yielding ciphertext and tag "ct" 164 * Open(key, nonce, aad, ct): Decrypt ciphertext "ct" using 165 associated data "aad" with secret key "key" and nonce "nonce", 166 returning plaintext message "pt" or an error 168 * Nk: The length in octets of a key for this algorithm 170 * Nn: The length in octets of a nonce for this algorithm 172 A set of concrete instantiations of these primitives is provided in 173 Section 6. Ciphersuite values are one octet long. 175 In the algorithms that follow, let "Nk" be the length in bytes of a 176 symmetric key suitable for encryption and decryption with the AEAD 177 scheme in use, and let "Nn" be the length of a in bytes of a suitable 178 nonce. 180 5.1. Key Encapsulation and Decapsulation 182 HPKE uses DH to generate an ephemeral secret that is shared between 183 the sender and the receiver, then uses this secret to generate one or 184 more (key, nonce) pairs for use with an Authenticated Encryption with 185 Associated Data (AEAD) algorithm. 187 In the below algorithms, the various functions and variables specific 188 to the underlying primitives (Expand, Nn, etc.) are understood to be 189 in the context of the specified ciphersuite. 191 The SetupI() procedure takes as input a ciphersuite (see Section 6), 192 peer public key, and info string and generates a shared secret value 193 and a public key that the receiver can use to recover shared secret. 195 Input: ciphersuite, pkR, info 197 1. (skE, pkE) = GenerateKeyPair() 198 2. zz = DH(skE, pkR) 199 3. secret = Extract(0^Nh, zz) 200 4. context = ciphersuite || Marshal(pkE) || Marshal(pkR) || info 201 6. keyIR = Expand(secret, "hpke key" || context, Nk) 202 8. nonceIR = Expand(secret, "hpke nonce" || context, Nn) 204 Output: pkE, keyIR, nonceIR 206 In step 3, the octet string "0^Nh" is the all-zero octet string of 207 length "Nh". Note that step 4 includes the recipient public key in 208 the key derivation step so that the derived key is bound to the 209 recipient. 211 The SetupR() procedure takes as input a ciphersuite, encapsulated 212 secret, secret key, and info string to produce a shared secret. 214 Input: ciphersuite, pkE, skR, info 216 1. zz = DH(skR, pkE) 217 2. secret = Extract(0^Nh, zz) 218 3. context = ciphersuite || Marshal(pkE) || Marshal(pkR) || info 219 4. keyIR = Expand(secret, "hpke key" || context, Nk) 220 5. nonceIR = Expand(secret, "hpke nonce" || context, Nn) 222 Output: keyIR, nonceIR 224 5.2. Encryption and Decryption 226 HPKE encryption "Encrypt()" and decryption "Decrypt()" are single- 227 shot so shared secrets are never re-used. "Encrypt()" takes as input 228 plaintext "pt" and associated data "ad" to encrypt, along with the 229 ciphersuite, Responder public key, and an info string, and produces a 230 ciphertext "ct" and encapsulated ephemeral key "secretIR", as 231 follows: 233 Input: ciphersuite, pkR, info, ad, pt 235 1. pkE, keyIR, nonceIR = SetupI(ciphersuite, pkR, info) 236 2. ct = Seal(keyIR, nonceIR, ad, pt) 238 Output: ct, pkE 240 Decryption "Decrypt()" mirrors encryption, as follows: 242 Input: ciphersuite, skR, pkE, info, ad, ct 244 1. keyIR, nonceIR = Decap(ciphersuite, pkE, pkR, info) 245 2. pt = Open(keyIR, nonceIR, ad, ct) 247 Output: pt 249 6. Ciphersuites 251 The HPKE variants as presented will function correctly for any 252 combination of primitives that provides the functions described 253 above. In this section, we provide specific instantiations of these 254 primitives for standard groups, including: Curve25519, Curve448 255 [RFC7748], and the NIST curves (P-256, P-384, P-512). 257 +-------------------------+---------+----------+-------------+------+ 258 | Configuration | DH | KDF | AEAD | Valu | 259 | | Group | | | e | 260 +-------------------------+---------+----------+-------------+------+ 261 | X25519-HKDF-SHA256-AES- | Curve25 | HKDF- | AES-GCM-128 | 0x01 | 262 | GCM-128 | 519 | SHA256 | | | 263 | | | | | | 264 | X25519-HKDF- | Curve25 | HKDF- | ChaCha20Pol | 0x02 | 265 | SHA256-ChaCha20Poly1305 | 519 | SHA256 | y1305 | | 266 | | | | | | 267 | X448-HKDF-SHA512-AES- | Curve44 | HKDF- | AES-GCM-256 | 0x03 | 268 | GCM-256 | 8 | SHA512 | | | 269 | | | | | | 270 | X448-HKDF- | Curve44 | HKDF- | ChaCha20Pol | 0x04 | 271 | SHA512-ChaCha20Poly1305 | 8 | SHA512 | y1305 | | 272 | | | | | | 273 | P256-HKDF-SHA256-AES- | P-256 | HKDF- | AES-GCM-128 | 0x05 | 274 | GCM-128 | | SHA256 | | | 275 | | | | | | 276 | P256-HKDF- | P-256 | HKDF- | ChaCha20Pol | 0x06 | 277 | SHA256-ChaCha20Poly1305 | | SHA256 | y1305 | | 278 | | | | | | 279 | P521-HKDF-SHA512-AES- | P-521 | HKDF- | AES-GCM-256 | 0x07 | 280 | GCM-256 | | SHA512 | | | 281 | | | | | | 282 | P521-HKDF- | P-521 | HKDF- | ChaCha20Pol | 0x08 | 283 | SHA512-ChaCha20Poly1305 | | SHA512 | y1305 | | 284 +-------------------------+---------+----------+-------------+------+ 286 For the NIST curves P-256 and P-521, the Marshal function of the DH 287 scheme produces the normal (non-compressed) representation of the 288 public key, according to [SECG]. When these curves are used, the 289 recipient of an HPKE ciphertext MUST validate that the ephemeral 290 public key "pkE" is on the curve. The relevant validation procedures 291 are defined in [keyagreement] 293 For the CFRG curves Curve25519 and Curve448, the Marshal function is 294 the identity function, since these curves already use fixed-length 295 octet strings for public keys. 297 The values "Nk" and "Nn" for the AEAD algorithms referenced above are 298 as follows: 300 +------------------+----+----+ 301 | AEAD | Nk | Nn | 302 +------------------+----+----+ 303 | AES-GCM-128 | 16 | 12 | 304 | | | | 305 | AES-GCM-256 | 32 | 12 | 306 | | | | 307 | ChaCha20Poly1305 | 32 | 12 | 308 +------------------+----+----+ 310 7. Security Considerations 312 [[ TODO ]] 314 8. IANA Considerations 316 [[ OPEN ISSUE: Should the above table be in an IANA registry? ]] 318 9. References 320 9.1. Normative References 322 [ANSI] "Public Key Cryptography for the Financial Services 323 Industry -- Key Agreement and Key Transport Using Elliptic 324 Curve Cryptography", n.d.. 326 [IEEE] "IEEE 1363a, Standard Specifications for Public Key 327 Cryptography - Amendment 1 -- Additional Techniques", 328 n.d.. 330 [ISO] "ISO/IEC 18033-2, Information Technology - Security 331 Techniques - Encryption Algorithms - Part 2 -- Asymmetric 332 Ciphers", n.d.. 334 [keyagreement] 335 Barker, E., Chen, L., Roginsky, A., and M. Smid, 336 "Recommendation for Pair-Wise Key Establishment Schemes 337 Using Discrete Logarithm Cryptography", National Institute 338 of Standards and Technology report, 339 DOI 10.6028/nist.sp.800-56ar2, May 2013. 341 [MAEA10] "A Comparison of the Standardized Versions of ECIES", 342 n.d., . 345 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 346 Requirement Levels", BCP 14, RFC 2119, 347 DOI 10.17487/RFC2119, March 1997, 348 . 350 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 351 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 352 . 354 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 355 for Security", RFC 7748, DOI 10.17487/RFC7748, January 356 2016, . 358 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 359 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 360 May 2017, . 362 [S01] "A Proposal for an ISO Standard for Public Key Encryption 363 (verison 2.1)", n.d., 364 . 366 [SECG] "Elliptic Curve Cryptography, Standards for Efficient 367 Cryptography Group, ver. 2", n.d., 368 . 370 9.2. Informative References 372 [I-D.ietf-mls-protocol] 373 Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and 374 R. Robert, "The Messaging Layer Security (MLS) Protocol", 375 draft-ietf-mls-protocol-03 (work in progress), January 376 2019. 378 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 379 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 380 . 382 Appendix A. Possible TODOs 384 The following extensions to the basic HPKE functions defined above 385 might be worth specifying: 387 o Use of general KEM - It could be useful to define the routines in 388 this document in terms of a general KEM, as opposed to just DH. 389 For example, there are currently more post-quantum KEM proposals 390 than DH proposals. 392 o Sender authentication - It is possible to enable a degree of 393 sender authentication by mixing in a long-term key for the sender 394 of a ciphertext as well as the recipient. This is done, for 395 example, in the libnacl "box" function. 397 o PSK authentication - A pre-shared key could be folded into the key 398 schedule as another form of authentication. 400 o Streaming (multi-message) encryption - In many use cases, it is 401 useful to amortize the cost of the DH operation over several AEAD 402 encryptions. 404 o Multiple recipients - It might be possible to add some 405 simplifications / assurances for the case where the same value is 406 being encrypted to multiple recipients. 408 o Test vectors - Obviously, we can provide decryption test vectors 409 in this document. In order to provide known-answer tests, we 410 would have to introduce a non-secure deterministic mode where the 411 ephemeral key pair is derived from the inputs. And to do that 412 safely, we would need to augment the decrypt function to detect 413 the deterministic mode and fail. 415 o A reference implementation in hacspec or similar 417 Authors' Addresses 419 Richard L. Barnes 420 Cisco 422 Email: rlb@ipv.sx 424 Karthik Bhargavan 425 Inria 427 Email: karthikeyan.bhargavan@inria.fr