idnits 2.17.1 draft-barnes-cfrg-hpke-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 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 (March 11, 2019) is 1872 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'MAEA10' is defined on line 533, 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: September 12, 2019 Inria 6 March 11, 2019 8 Hybrid Public Key Encryption 9 draft-barnes-cfrg-hpke-01 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 September 12, 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. Cryptographic Dependencies . . . . . . . . . . . . . . . . . 3 59 5.1. DH-Based KEM . . . . . . . . . . . . . . . . . . . . . . 5 60 6. Hybrid Public Key Encryption . . . . . . . . . . . . . . . . 5 61 6.1. Encryption to a Public Key . . . . . . . . . . . . . . . 6 62 6.2. Authentication using a Pre-Shared Key . . . . . . . . . . 7 63 6.3. Authentication using an Asymmetric Key . . . . . . . . . 8 64 6.4. Encryption and Decryption . . . . . . . . . . . . . . . . 9 65 7. Ciphersuites . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 69 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 70 10.2. Informative References . . . . . . . . . . . . . . . . . 12 71 Appendix A. Possible TODOs . . . . . . . . . . . . . . . . . . . 13 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 74 1. Introduction 76 Hybrid public-key encryption (HPKE) is a substantially more efficient 77 solution than traditional public key encryption techniques such as 78 those based on RSA or ElGamal. Encrypted messages convey a single 79 ciphertext and authentication tag alongside a short public key, which 80 may be further compressed. The key size and computational complexity 81 of elliptic curve cryptographic primitives for authenticated 82 encryption therefore make it compelling for a variety of use case. 83 This type of public key encryption has many applications in practice, 84 for example, in PGP [RFC6637] and in the developing Messaging Layer 85 Security protocol [I-D.ietf-mls-protocol]. 87 Currently, there are numerous competing and non-interoperable 88 standards and variants for hybrid encryption, including ANSI X9.63 89 [ANSI], IEEE 1363a [IEEE], ISO/IEC 18033-2 [ISO], and SECG SEC 1 90 [SECG]. Lack of a single standard makes selection and deployment of 91 a compatible, cross-platform and ecosystem solution difficult to 92 define. This document defines an HPKE scheme that provides a subset 93 of the functions provided by the collection of schemes above, but 94 specified with sufficient clarity that they can be interoperably 95 implemented and formally verified. 97 2. Requirements Notation 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 BCP14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 3. Security Properties 107 As a hybrid authentication encryption algorithm, we desire security 108 against (adaptive) chosen ciphertext attacks (IND-CCA2 secure). The 109 HPKE variants described in this document achieve this property under 110 the Random Oracle model assuming the gap Computational Diffie Hellman 111 (CDH) problem is hard [S01]. 113 4. Notation 115 The following terms are used throughout this document to describe the 116 operations, roles, and behaviors of HPKE: 118 o Initiator (I): Sender of an encrypted message. 120 o Responder (R): Receiver of an encrypted message. 122 o Ephemeral (E): A fresh random value meant for one-time use. 124 o "(skX, pkX)": A KEM key pair used in role X; "skX" is the private 125 key and "pkX" is the public key 127 o "pk(sk)": The public key corresponding to a private key 129 o "len(x)": The one-octet length of the octet string "x" 131 o "+": Concatenation of octet strings; "0x01 + 0x02 = 0x0102" 133 o "*": Repetition of an octet string; "0x01 * 4 = 0x01010101" 135 o "^": XOR of octet strings; "0xF0F0 ^ 0x1234 = 0xE2C4" 137 5. Cryptographic Dependencies 139 HPKE variants rely on the following primitives: 141 o A Key Encapsulation Mechanism (KEM): 143 * GenerateKeyPair(): Generate a key pair (sk, pk) 144 * Marshal(pk): Produce a fixed-length octet string encoding the 145 public key "pk" 147 * Unmarshal(enc): Parse a fixed-length octet string to recover a 148 public key 150 * Encap(pk): Generate an ephemeral symmetric key and a fixed- 151 length encapsulation of that key that can be decapsulated by 152 the holder of the private key corresponding to pk 154 * Decap(enc, sk): Use the private key "sk" to recover the 155 ephemeral symmetric key from its encapsulated representation 156 "enc" 158 * AuthEncap(pkR, skI) (optional): Same as Encap(), but the 159 outputs encode an assurance that the ephemeral shared key is 160 known only to the holder of the private key "skI" 162 * AuthDecap(skI, pkR) (optional): Same as Decap(), but the holder 163 of the private key "skI" is assured that the ephemeral shared 164 key is known only to the holder of the private key 165 corresponding to "pkI" 167 o A Key Derivation Function: 169 * Extract(salt, IKM): Extract a pseudorandom key of fixed length 170 from input keying material "IKM" and an optional octet string 171 "salt" 173 * Expand(PRK, info, L): Expand a pseudorandom key "PRK" using 174 optional string "info" into "L" bytes of output keying material 176 * Nh: The output size of the Extract function 178 o An AEAD encryption algorithm [RFC5116]: 180 * Seal(key, nonce, aad, pt): Encrypt and authenticate plaintext 181 "pt" with associated data "aad" using secret key "key" and 182 nonce "nonce", yielding ciphertext and tag "ct" 184 * Open(key, nonce, aad, ct): Decrypt ciphertext "ct" using 185 associated data "aad" with secret key "key" and nonce "nonce", 186 returning plaintext message "pt" or the error value "OpenError" 188 * Nk: The length in octets of a key for this algorithm 190 * Nn: The length in octets of a nonce for this algorithm 192 A set of concrete instantiations of these primitives is provided in 193 Section 7. Ciphersuite values are two octets long. 195 5.1. DH-Based KEM 197 Suppose we are given a Diffie-Hellman group that provides the 198 following operations: 200 o GenerateKeyPair(): Generate an ephemeral key pair "(sk, pk)" for 201 the DH group in use 203 o DH(sk, pk): Perform a non-interactive DH exchange using the 204 private key sk and public key pk to produce a shared secret 206 o Marshal(pk): Produce a fixed-length octet string encoding the 207 public key "pk" 209 Then we can construct a KEM (which we'll call "DHKEM") in the 210 following way: 212 def Encap(pkR): 213 skE, pkE = GenerateKeyPair() 214 zz = DH(skE, pkR) 215 enc = Marshal(pkE) 216 return zz, enc 218 def Decap(enc, skR): 219 pkE = Unmarshal(enc) 220 return DH(skR, pkE) 222 def AuthEncap(pkR, skI): 223 skE, pkE = GenerateKeyPair() 224 zz = DH(skE, pkR) + DH(skI, pkR) 225 enc = Marshal(pkE) 226 return zz, enc 228 def AuthDecap(enc, skR, pkI): 229 pkE = Unmarshal(enc) 230 return DH(skR, pkE) + DH(skR, pkI) 232 The Marshal and GenerateKeyPair functions are the same as for the 233 underlying DH group. 235 6. Hybrid Public Key Encryption 237 In this section, we define a few HPKE variants. All cases take a 238 plaintext "pt" and a recipient public key "pkR" and produce an 239 ciphertext "ct" and an encapsulated key "enc". These outputs are 240 constructed so that only the holder of the private key corresponding 241 to "pkR" can decapsulate the key from "enc" and decrypt the 242 ciphertext. All of the algorithms also take an "info" parameter that 243 can be used to influence the generation of keys (e.g., to fold in 244 identity information) and an "aad" parameter that provides Additional 245 Authenticated Data to the AEAD algorithm in use. 247 In addition to the base case of encrypting to a public key, we 248 include two authenticated variants, one of which authenticates 249 possession of a pre-shared key, and one of which authenticates 250 possession of a KEM private key. The following one-octet values will 251 be used to distinguish between modes: 253 +-----------+-------+ 254 | Mode | Value | 255 +-----------+-------+ 256 | mode_base | 0x00 | 257 | | | 258 | mode_psk | 0x01 | 259 | | | 260 | mode_auth | 0x02 | 261 +-----------+-------+ 263 All of these cases follow the same basic two-step pattern: 265 1. Set up an encryption context that is shared between the sender 266 and the recipient 268 2. Use that context to encrypt or decrypt content 270 A "context" encodes the AEAD algorithm and key in use, and manages 271 the nonces used so that the same nonce is not used with multiple 272 plaintexts. 274 The procedures described in this session are laid out in a Python- 275 like pseudocode. The ciphersuite in use is left implicit. 277 6.1. Encryption to a Public Key 279 The most basic function of an HPKE scheme is to enable encryption for 280 the holder of a given KEM private key. The "SetupBaseI()" and 281 "SetupBaseR()" procedures establish contexts that can be used to 282 encrypt and decrypt, respectively, for a given private key. 284 The the shared secret produced by the KEM is combined via the KDF 285 with information describing the key exchange, as well as the explicit 286 "info" parameter provided by the caller. 288 Note that the "SetupCore()" method is also used by the other HPKE 289 variants describe below. The value "0*Nh" in the "SetupBase()" 290 procedure represents an all-zero octet string of length "Nh". 292 def SetupCore(mode, secret, kemContext, info): 293 context = ciphersuite + mode + 294 len(kemContext) + kemContext + 295 len(info) + info 296 key = Expand(secret, "hpke key" + context, Nk) 297 nonce = Expand(secret, "hpke nonce" + context, Nn) 298 return Context(key, nonce) 300 def SetupBase(pkR, zz, enc, info): 301 kemContext = enc + pkR 302 secret = Extract(0\*Nh, zz) 303 return SetupCore(mode_base, secret, kemContext, info) 305 def SetupBaseI(pkR, info): 306 zz, enc = Encap(pkR) 307 return SetupBase(pkR, zz, enc, info) 309 def SetupBaseR(enc, skR, info): 310 zz = Decap(enc, skR) 311 return SetupBase(pk(skR), zz, enc, info) 313 Note that the context construction in the SetupCore procedure is 314 equivalent to serializing a structure of the following form in the 315 TLS presentation syntax: 317 struct { 318 uint16 ciphersuite; 319 uint8 mode; 320 opaque kemContext<0..255>; 321 opaque info<0..255>; 322 } HPKEContext; 324 6.2. Authentication using a Pre-Shared Key 326 This variant extends the base mechansism by allowing the recipient to 327 authenticate that the sender possessed a given pre-shared key (PSK). 328 We assume that both parties have been provisioned with both the PSK 329 value "psk" and another octet string "pskID" that is used to identify 330 which PSK should be used. 332 The primary differences from the base case are: 334 o The PSK is used as the "salt" input to the KDF (instead of 0) 335 o The PSK ID is added to the context string used as the "info" input 336 to the KDF 338 This mechanism is not suitable for use with a low-entropy password as 339 the PSK. A malicious recipient that does not possess the PSK can use 340 decryption of a plaintext as an oracle for performing offline 341 dictionary attacks. 343 def SetupPSK(pkR, psk, pskID, zz, enc, info): 344 kemContext = enc + pkR + pskID 345 secret = Extract(psk, zz) 346 return SetupCore(mode_psk, secret, kemContext, info) 348 def SetupPSKI(pkR, psk, pskID, info): 349 zz, enc = Encap(pkR) 350 return SetupPSK(pkR, psk, pskID, zz, enc, info) 352 def SetupPSKR(enc, skR, psk, pskID, info): 353 zz = Decap(enc, skR) 354 return SetupPSK(pk(skR), psk, pskID, zz, enc, info) 356 6.3. Authentication using an Asymmetric Key 358 This variant extends the base mechansism by allowing the recipient to 359 authenticate that the sender possessed a given KEM private key. This 360 assurance is based on the assumption that "AuthDecap(enc, skR, pkI)" 361 produces the correct shared secret only if the encapsulated value 362 "enc" was produced by "AuthEncap(pkR, skI)", where "skI" is the 363 private key corresponding to "pkI". In other words, only two people 364 could have produced this secret, so if the recipient is one, then the 365 sender must be the other. 367 The primary differences from the base case are: 369 o The calls to "Encap" and "Decap" are replaced with calls to 370 "AuthEncap" and "AuthDecap". 372 o The initiator public key is added to the context string used as 373 the "info" input to the KDF 375 Obviously, this variant can only be used with a KEM that provides 376 "AuthEncap()" and "AuthDecap()" procuedures. 378 This mechanism authenticates only the key pair of the initiator, not 379 any other identity. If an application wishes to authenticate some 380 other identity for the sender (e.g., an email address or domain 381 name), then this identity should be included in the "info" parameter 382 to avoid unknown key share attacks. 384 def SetupAuth(pkR, pkI, zz, enc, info): 385 kemContext = enc + pkR + pkI 386 secret = Extract(0*Nh, zz) 387 return SetupCore(mode_auth, secret, kemContext, info) 389 def SetupAuthI(pkR, skI, info): 390 zz, enc = AuthEncap(pkR, skI) 391 return SetupAuth(pkR, pk(skI), zz, enc, info) 393 def SetupAuthR(enc, skR, pkI, info): 394 zz = AuthDecap(enc, skR, pkI) 395 return SetupAuth(pk(skR), pkI, zz, enc, info) 397 6.4. Encryption and Decryption 399 HPKE allows multiple encryption operations to be done based on a 400 given setup transaction. Since the public-key operations involved in 401 setup are typically more expensive than symmetric encryption or 402 decryption, this allows applications to "amortize" the cost of the 403 public-key operations, reducing the overall overhead. 405 In order to avoid nonce reuse, however, this decryption must be 406 stateful. Each of the setup procedures above produces a context 407 object that stores the required state: 409 o The AEAD algorithm in use 411 o The key to be used with the AEAD algorithm 413 o A base nonce value 415 o A sequence number (initially 0) 417 All of these fields except the sequence number are constant. The 418 sequence number is used to provide nonce uniqueness: The nonce used 419 for each encryption or decryption operation is the result of XORing 420 the base nonce with the current sequence number, encoded as a big- 421 endian integer of the same length as the nonce. Implementations MAY 422 use a sequence number that is shorter than the nonce (padding on the 423 left with zero), but MUST return an error if the sequence number 424 overflows. 426 Each encryption or decryption operation increments the sequence 427 number for the context in use. A given context SHOULD be used either 428 only for encryption or only for decryption. 430 It is up to the application to ensure that encryptions and 431 decryptions are done in the proper sequence, so that the nonce values 432 used for encryption and decryption line up. 434 def Context.Nonce(seq): 435 encSeq = encode\_big\_endian(seq, len(self.nonce)) 436 return self.nonce ^ encSeq 438 def Context.Seal(aad, pt): 439 ct = Seal(self.key, self.Nonce(self.seq), aad, pt) 440 self.seq += 1 441 return ct 443 def Context.Open(aad, ct): 444 pt = Open(self.key, self.Nonce(self.seq), aad, pt) 445 if pt == OpenError: 446 return OpenError 447 self.seq += 1 448 return pt 450 7. Ciphersuites 452 The HPKE variants as presented will function correctly for any 453 combination of primitives that provides the functions described 454 above. In this section, we provide specific instantiations of these 455 primitives for standard groups, including: Curve25519, Curve448 456 [RFC7748], and the NIST curves P-256 and P-512. 458 +--------+-------------------+-------------+------------------+ 459 | Value | KEM | KDF | AEAD | 460 +--------+-------------------+-------------+------------------+ 461 | 0x0001 | DHKEM(P-256) | HKDF-SHA256 | AES-GCM-128 | 462 | | | | | 463 | 0x0002 | DHKEM(P-256) | HKDF-SHA256 | ChaCha20Poly1305 | 464 | | | | | 465 | 0x0002 | DHKEM(Curve25519) | HKDF-SHA256 | AES-GCM-128 | 466 | | | | | 467 | 0x0002 | DHKEM(Curve25519) | HKDF-SHA256 | ChaCha20Poly1305 | 468 | | | | | 469 | 0x0001 | DHKEM(P-521) | HKDF-SHA512 | AES-GCM-256 | 470 | | | | | 471 | 0x0002 | DHKEM(P-521) | HKDF-SHA512 | ChaCha20Poly1305 | 472 | | | | | 473 | 0x0002 | DHKEM(Curve448) | HKDF-SHA512 | AES-GCM-256 | 474 | | | | | 475 | 0x0002 | DHKEM(Curve448) | HKDF-SHA512 | ChaCha20Poly1305 | 476 +--------+-------------------+-------------+------------------+ 478 For the NIST curves P-256 and P-521, the Marshal function of the DH 479 scheme produces the normal (non-compressed) representation of the 480 public key, according to [SECG]. When these curves are used, the 481 recipient of an HPKE ciphertext MUST validate that the ephemeral 482 public key "pkE" is on the curve. The relevant validation procedures 483 are defined in [keyagreement] 485 For the CFRG curves Curve25519 and Curve448, the Marshal function is 486 the identity function, since these curves already use fixed-length 487 octet strings for public keys. 489 The values "Nk" and "Nn" for the AEAD algorithms referenced above are 490 as follows: 492 +------------------+----+----+ 493 | AEAD | Nk | Nn | 494 +------------------+----+----+ 495 | AES-GCM-128 | 16 | 12 | 496 | | | | 497 | AES-GCM-256 | 32 | 12 | 498 | | | | 499 | ChaCha20Poly1305 | 32 | 12 | 500 +------------------+----+----+ 502 8. Security Considerations 504 [[ TODO ]] 506 9. IANA Considerations 508 [[ OPEN ISSUE: Should the above table be in an IANA registry? ]] 510 10. References 512 10.1. Normative References 514 [ANSI] "Public Key Cryptography for the Financial Services 515 Industry -- Key Agreement and Key Transport Using Elliptic 516 Curve Cryptography", n.d.. 518 [IEEE] "IEEE 1363a, Standard Specifications for Public Key 519 Cryptography - Amendment 1 -- Additional Techniques", 520 n.d.. 522 [ISO] "ISO/IEC 18033-2, Information Technology - Security 523 Techniques - Encryption Algorithms - Part 2 -- Asymmetric 524 Ciphers", n.d.. 526 [keyagreement] 527 Barker, E., Chen, L., Roginsky, A., and M. Smid, 528 "Recommendation for Pair-Wise Key Establishment Schemes 529 Using Discrete Logarithm Cryptography", National Institute 530 of Standards and Technology report, 531 DOI 10.6028/nist.sp.800-56ar2, May 2013. 533 [MAEA10] "A Comparison of the Standardized Versions of ECIES", 534 n.d., . 537 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 538 Requirement Levels", BCP 14, RFC 2119, 539 DOI 10.17487/RFC2119, March 1997, 540 . 542 [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated 543 Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, 544 . 546 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 547 for Security", RFC 7748, DOI 10.17487/RFC7748, January 548 2016, . 550 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 551 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 552 May 2017, . 554 [S01] "A Proposal for an ISO Standard for Public Key Encryption 555 (verison 2.1)", n.d., 556 . 558 [SECG] "Elliptic Curve Cryptography, Standards for Efficient 559 Cryptography Group, ver. 2", n.d., 560 . 562 10.2. Informative References 564 [I-D.ietf-mls-protocol] 565 Barnes, R., Millican, J., Omara, E., Cohn-Gordon, K., and 566 R. Robert, "The Messaging Layer Security (MLS) Protocol", 567 draft-ietf-mls-protocol-03 (work in progress), January 568 2019. 570 [RFC6637] Jivsov, A., "Elliptic Curve Cryptography (ECC) in 571 OpenPGP", RFC 6637, DOI 10.17487/RFC6637, June 2012, 572 . 574 Appendix A. Possible TODOs 576 The following extensions might be worth specifying: 578 o Multiple recipients - It might be possible to add some 579 simplifications / assurances for the case where the same value is 580 being encrypted to multiple recipients. 582 o Test vectors - Obviously, we can provide decryption test vectors 583 in this document. In order to provide known-answer tests, we 584 would have to introduce a non-secure deterministic mode where the 585 ephemeral key pair is derived from the inputs. And to do that 586 safely, we would need to augment the decrypt function to detect 587 the deterministic mode and fail. 589 o A reference implementation in hacspec or similar 591 Authors' Addresses 593 Richard L. Barnes 594 Cisco 596 Email: rlb@ipv.sx 598 Karthik Bhargavan 599 Inria 601 Email: karthikeyan.bhargavan@inria.fr