diff --git a/draft-connolly-cfrg-xwing-kem.md b/draft-connolly-cfrg-xwing-kem.md index e6d80e3..aa8008a 100644 --- a/draft-connolly-cfrg-xwing-kem.md +++ b/draft-connolly-cfrg-xwing-kem.md @@ -1,5 +1,5 @@ --- -title: "X-Wing: A general-purpose KEM" +title: "X-Wing: general-purpose hybrid post-quantum KEM" abbrev: xwing category: info @@ -45,6 +45,7 @@ normative: informative: I-D.driscoll-pqt-hybrid-terminology: + I-D.ounsworth-cfrg-kem-combiners: I-D.ietf-tls-hybrid-design: HASHEDDH: target: https://eprint.iacr.org/2022/1230.pdf @@ -104,6 +105,7 @@ informative: - ins: J. Schanck RFC9180: + RFC7748: NISTR3: target: https://csrc.nist.gov/News/2022/pqc-candidates-to-be-standardized-and-round-4 title: 'PQC Standardization Process: Announcing Four Candidates to be Standardized, Plus Fourth Round Candidates' @@ -117,50 +119,191 @@ informative: --- abstract -This document specifies a general-purpose key encapsulation mechanism (KEM) that -commits to public key material and ciphertext material as part of computing the -shared secret. KEMs with these properties are attractive for protocols that are -looking to replace pure Diffie-Hellman key agreement. - +This memo defines X-Wing, a general-purpose post-quantum/traditional + hybrid key encapsulation mechanism (PQ/T KEM) + built on X25519 and ML-KEM-768. --- middle # Introduction -A KEM is a three-tuple of algorithms (*KeyGen*, *Encapsulate*, *Decapsulate*): +## Warning: ML-KEM-768 has not been standardised + +X-Wing uses ML-KEM-768, which has not been standardised yet. +Thus X-Wing is not finished, yet, and should not be used, yet. + +## Motivation + +There are many choices that can be made when + specifying a hybrid KEM: + the constituent KEMs; + their security levels; + the combinber; + and the hash within, to name but a few. +Having too many similar options are a burden to the ecosystem. +The aim of X-Wing is to provide a concrete, simple choice + for post-quantum hybrid KEM, + that should be suitable for the vast majority of use cases. + +## Design goals + +1. By making concrete choices, we can simplify and improve many + aspects of X-Wing as compared to a more generic combiner. + + - Simplicity of definition. For one, because all shared secrets + and cipher texts are fixed length, we do not need to encode the length. + + - Its security analysis. Because ML-KEM-768 already assumes QROM, we + do not need to complicate the analysis of X-Wing by considering + weaker models. + + - Its performance. By using SHA3-256 in the combiner, which matches + the hashing in ML-KEM, this hash can be computed in one go on platforms + where two-way Keccak is available. + +2. We aim for "128 bits" security (NIST PQC level 1). + Although at the moment there is no + peer-reviewed evidence that ML-KEM-512 does not reach this + level, we would like to hedge against future cryptanalytic + improvements, and feel ML-KEM-768 provides a comfortable + margin. + +3. We aim for X-Wing to be usable for most applications, + including specifically HPKE {{RFC9180}}. - - *KeyGen* takes no inputs and generates a private key and a public key; - - *Encapsulate* takes as input a public key and produces as output - a ciphertext and a shared secret; - - *Decapsulate* takes as input a ciphertext and a private key and - produces a shared secret. +## Not an interactive key-agreement -Like DH, a KEM can be used as an unauthenticated key-agreement -protocol, for example in TLS {{HYBRID}} {{XYBERTLS}}. -However, unlike DH, a KEM-based key agreement is *interactive*, -because the party executing Encapsulate can compute its protocol -message (the ciphertext) only after having received the input -(public key) from the party running *KeyGen* and *Decapsulate*. +Traditionally most protocols use a Diffie-Hellman (DH) style + non-interactive key-agreement. +In many cases, a DH key agreement can be replaced by + the interactive key-agreement afforded by a KEM + without change in the protocol flow. +One notable example is TLS {{HYBRID}} {{XYBERTLS}}. +However, not all uses of DH can be replaced in a straight-forward + manner by a plain KEM. +## Not an authenticated KEM + +In particular, X-Wing is not, borrowing the language + of {{RFC9180}}, an *authenticated* KEM. + +## Comparisons + +X-Wing is most similar to HPKE's X25519Kyber768Draft00 {{XYBERHPKE}}. +The differences are: + +1. X-Wing uses the final version of ML-KEM-768. + +2. X-Wing hashes the shared secrets, to be usable outside of HPKE. + +3. X-Wing has a simpler combiner by flattening DHKEM(X25519) + into the final hash. + +There is also a different KEM called X25519Kyber768Draft00 {{XYBERTLS}} +which is used in TLS. This one should not be used outside of TLS, +as it assumes the presence of the TLS transcript to ensure non malleability. + +TODO comparison with {{I-D.ounsworth-cfrg-kem-combiners}} # Conventions and Definitions {::boilerplate bcp14-tagged} -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", -"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this -document are to be interpreted as described in BCP 14 {{RFC2119}} {{RFC8174}} -when, and only when, they appear in all capitals, as shown here. - This document is consistent with all terminology defined in {{I-D.driscoll-pqt-hybrid-terminology}}. -# X-KEM +`concat(a, b)` returns the concatenation of byte strings. + +`random(n)` returns `n` bytes from a cryptographically secure + random number generator. + +# Construction + +## Key derivation + +An X-Wing keypair (private key, public key) is derived from entropy +as follows. + +~~~ +def DeriveKeyPair(ikm): + seed = SHAKE128(ikm, 96) + seed1 = seed[0:32] + seed2 = seed[32:96] + pk1 = X25519(seed1, 9) + (sk2, pk2) = ML-KEM-768.DeriveKeyPair(seed2) + return concat(seed1, sk2), concat(pk1, pk2) + +def GenerateKeyPair(): + return DeriveKeyPair(random(32)) +~~~ + +Here X25519() is the function defined in {{Section 5 of RFC7748}}. Note +that 9 corresponds to the standard base point. + +ML-KEM-768.DeriveKeyPair() is the function defined in TODO. + +ikm SHOULD be at least 32 bytes in length. + +## Encapsulation + +Given an X-Wing public key `pk`, encapsulation proceeds as follows. + +~~~~ +def Combiner(ss1, ss2, ct1, ct2, pk1): + return SHA3-256(concat( + XWingDS, + ss1, + ss2, + ct1, + ct2, + pk1 + )) + +def Encapsulate(pk): + pk1 = pk[0:32] + pk2 = pk[32:TODO] + esk1 = random(32) + ct1 = X25519(esk1, 9) + ss1 = X25519(esk1, pk1) + (ss2, ct2) = ML-KEM-768.Encapsulate(pk2) + return (Combiner(ss1, ss2, ct1, ct2, pk1), concat(ct1, ct2)) +~~~~ + +Here ML-KEM-768.Encapsulate() is the function defined in TODO. + +XWingDS is the following 48 byte ASCII string + +~~~ +XWingDS = concat( + "======> ", + " \ \ ", + " / ||||||||)", + "======> " +) +~~~ + +[ TODO prettier ASCII art ] + + +## Decapsulation + +~~~ +def Decapsulate(ct, sk, pk): + ct1 = ct[0:32] + ct2 = ct[32:TODO] + sk1 = sk[0:32] + sk2 = sk[32:TODO] + pk1 = pk[0:32] + ss1 = X25519(ct1, sk1) + ss2 = ML-KEM-768.Decapsulate(ct2, sk2) + return Combiner(ss1, ss2, ct1, ct2, pk1) +~~~ + +### -``` -SS_X-KEM = SHA3-256("X-WING-ASCII-ART" || SS_X25519 || SS_ML-KEM-768 || CT_X25519 || CT_ML-KEM-768 || PK_X25519) -``` +## Use in HPKE +TODO. # Security Considerations @@ -169,7 +312,7 @@ TODO Security # IANA Considerations -This document has no IANA actions. +TODO --- back