Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Aligned with X-Wing #11

Merged
merged 13 commits into from
Jul 7, 2024
Merged

Aligned with X-Wing #11

Changes from 2 commits
Commits
Show all changes
13 commits
Select commit Hold shift + click to select a range
21c3b68
Aligned with X-Wing
ounsworth Jan 27, 2024
5fb7140
Aligned with X-Wing
ounsworth Jan 27, 2024
e206720
Changed KMAC to SHA3
ounsworth Feb 3, 2024
6ef02a4
Typo in example combiner
ounsworth Feb 6, 2024
b7ef4e9
Typo
ounsworth Feb 6, 2024
d21cfe7
Ran aspell spell check
ounsworth Feb 6, 2024
aa75908
Merge branch 'mikeo_xwing' of github.com:lamps-wg/draft-composite-kem…
ounsworth Feb 6, 2024
c9e59f5
Typo
ounsworth Feb 6, 2024
645d48b
Addressing Ilari comments
ounsworth Feb 6, 2024
a06a8eb
Added the RSA ciphertext back into the KDF
ounsworth Feb 16, 2024
f11d4b9
#26
ounsworth Jul 6, 2024
304a37d
More alignment with X-Wing
ounsworth Jul 6, 2024
b355af2
Top-to-bottom editorial pass
ounsworth Jul 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
173 changes: 109 additions & 64 deletions draft-ietf-lamps-pq-composite-kem.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,8 +60,7 @@ normative:
RFC8174:
RFC8410:
RFC8411:
I-D.draft-ietf-lamps-rfc5990bis-01:
I-D.draft-ounsworth-lamps-cms-dhkem-00:
I-D.draft-ietf-lamps-rfc5990bis-04:
I-D.draft-housley-lamps-cms-sha3-hash-01:
ANS-X9.44:
title: "Public Key
Expand Down Expand Up @@ -133,50 +132,56 @@ informative:
I-D.draft-ietf-lamps-kyber-certificates-01:
I-D.draft-becker-guthrie-noncomposite-hybrid-auth-00:
I-D.draft-housley-lamps-cms-kemri-02:
X-Wing:
title: "X-Wing The Hybrid KEM You’ve Been Looking For"
date: 2024-01-09
author:
-
ins: M. Barbosa
name: Manuel Barbosa
-
ins: D. Connolly
name: Deirdre Connolly
-
ins: J. Duarte
name: João Diogo Duarte
-
ins: A. Kaiser
name: Aaron Kaiser
-
ins: P. Schwabe
name: Peter Schwabe
-
ins: K. Varner
name: Karolin Varner
-
ins: B. Westerbaan
name: Bas Westerbaan
target: https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.203.ipd.pdf
ounsworth marked this conversation as resolved.
Show resolved Hide resolved


--- abstract

This document defines Post-Quantum / Traditional composite Key Encapsulation Mechanism (KEM) algorithms suitable for use within X.509 and PKIX and CMS protocols. Composite algorithms are provided which combine ML-KEM with RSA-KEM and ECDH-KEM. The provided set of composite algorithms should meet most Internet needs.

This document assumes that all component algorithms are KEMs, and therefore it depends on {{I-D.ietf-lamps-rfc5990bis}} and {{I-D.ounsworth-lamps-cms-dhkem}} in order to promote RSA and ECDH respectively into KEMs. For the purpose of combining KEMs, the combiner function from {{I-D.ounsworth-cfrg-kem-combiners}} is used. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in {{I-D.housley-lamps-cms-kemri}}.
This document defines Post-Quantum / Traditional composite Key Encapsulation Mechanism (KEM) algorithms suitable for use within X.509 and PKIX and CMS protocols. Composite algorithms are provided which combine ML-KEM with RSA-KEM, ECDH, X25519, and X448. The provided set of composite algorithms should meet most CMS needs. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in {{I-D.housley-lamps-cms-kemri}}.

<!-- End of Abstract -->


--- middle

# Changes in version -01 and -02

Changes affecting interoperability:

* Re-worked wire format and ASN.1 to remove vestiges of Generics.
* Changed all `SEQUENCE OF SIZE (2..MAX)` to `SEQUENCE OF SIZE (2)`.
* Changed the definition of `CompositeKEMPublicKey` from `SEQUENCE OF SubjectPublicKeyInfo` to `SEQUENCE OF BIT STRING` since with complete removal of Generic Composites, there is no longer any need to carry the component AlgorithmIdentifiers.
* Removed CompositeKEMParams since all params are now explicit in the OID.
* Defined `KeyGen()`, `Encaps()`, and `Decaps()` for a composite KEM algorithm.
* Removed the discussion of KeyTrans -> KEM and KeyAgree -> KEM promotions, and instead simply referenced {{I-D.ietf-lamps-rfc5990bis}} and {{I-D.ounsworth-lamps-cms-dhkem}}.
* Made RSA keys fixed-length at 2048 and 3072, both at the NIST Level 1 / AES-128 security level.
* Re-worked section 4.1 (id-MLKEM768-RSA3072-KMAC256) to Reference 5990bis and its updated structures.
* Removed RSA-KEM KDF params and make them implied by the OID; ie provide a profile of 5990bis.
* Aligned combiner with draft-ounsworth-cfrg-kem-combiners-04.
* Added id-MLKEM512-RSA2048-KMAC128 so that we have an RSA 2048 option.

Editorial changes:

* Refactored to use MartinThomson github template.
* Made this document standalone by folding in the minimum necessary content from composite-keys and dropping the cross-reference to composite-sigs.
* Added a paragraph describing how to reconstitute component SPKIs.
* Added an Implementation Consideration about FIPS validation where only one component algorithm is FIPS-approved.
* Shortened the abstract (moved some content into Intro).
* Brushed up the Security Considerations.
* Made a proper IANA Considerations section.
* Rename "Kyber" to "ML-KEM".
# Changes in version -03

Changes to sync with X-Wing:

- Removed ML-KEM ciphertext from KDF.
- Removed RSA-KEM ciphertext from KDF.
- Removed references to I-D.ounsworth-lamps-cms-dhkem since we'll just inline it and don't need a DHKEM wrapper.


Still to do in a future version:

`[ ]` We need PEM samples … 118 hackathon? OQS friends? David @ BC? The right format for samples is probably to follow the hackathon ... a Dilithium or ECDSA trust anchor certificate, a composite KEM end entity certificate, and a CMS EnvolepedData sample encrypted for that composite KEM certificate.

`[ ]` Open question: do we need to incluede the ECDH, X25519, X448, and RSA public keys is the KDF? X-Wing does, but previous versions of this spec do not.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good question, not sure yet


# Introduction {#sec-intro}

Expand Down Expand Up @@ -249,7 +254,7 @@ We borrow here the definition of a key encapsulation mechanism (KEM) from {{I-D.

The KEM interface defined above differs from both traditional key transport mechanism (for example for use with KeyTransRecipientInfo defined in {{RFC5652}}), and key agreement (for example for use with KeyAgreeRecipientInfo defined in {{RFC5652}}).

The KEM interface was chosen as the interface for a composite key establishment because it allows for arbitrary combinations of component algorithm types since both key transport and key agreement mechanisms can be promoted into KEMs. This specification uses the Post-Quantum KEM ML-KEM as specified in {{I-D.ietf-lamps-kyber-certificates}} and [FIPS.203-ipd]. For Traditional KEMs, this document relies on the RSA-KEM construction defined in {{I-D.ietf-lamps-rfc5990bis}} and the Elliptic Curve DHKEM defined in {{I-D.ounsworth-lamps-cms-dhkem}}.
The KEM interface was chosen as the interface for a composite key establishment because it allows for arbitrary combinations of component algorithm types since both key transport and key agreement mechanisms can be promoted into KEMs. This specification uses the Post-Quantum KEM ML-KEM as specified in {{I-D.ietf-lamps-kyber-certificates}} and [FIPS.203-ipd]. For Traditional KEMs, this document relies on the RSA-KEM construction defined in {{I-D.ietf-lamps-rfc5990bis}} while the Elliptic Curve Diffie-Hellman key agreement schemes are inlined directly.

A composite KEM allows two or more underlying key transport, key agreement, or KEM algorithms to be combined into a single cryptographic operation by performing each operation, transformed to a KEM as outline above, and using a specified combiner function to combine the two or more component shared secrets into a single shared secret.

Expand Down Expand Up @@ -280,7 +285,7 @@ Encaps(pk):
~~~
{: #alg-composite-encaps title="Composite Encaps(pk)"}

where `Combiner(ct1, ss1, ct2, ss2, fixedInfo)` is defined in {{sec-kem-combiner}} and `CompositeCiphertextValue` is defined in {{sec-CompositeCiphertextValue}}.
where `Combiner(ct1, ss1, ct2, ss2, fixedInfo)` is defined in general in {{sec-kem-combiner}} with specific instantiations per composite KEM algorithm in {{sec-alg-ids}} and `CompositeCiphertextValue` is defined in {{sec-CompositeCiphertextValue}}.

### Composite Decaps

Expand Down Expand Up @@ -445,7 +450,9 @@ A composite KEM and `CompositeCipherTextValue` MAY be associated with a composit

TODO: as per https://www.enisa.europa.eu/publications/post-quantum-cryptography-integration-study section 4.2, might need to specify behaviour in light of KEMs with a non-zero failure probility.

This document follows the construction of {{I-D.ounsworth-cfrg-kem-combiners}}, which is repeated here for clarity and simplified to take two imput shared secrets:
This document follows the construction of {{I-D.ounsworth-cfrg-kem-combiners}}, which is repeated here for clarity, however it has been simplified to take two imput shared secrets, and to take advantage of ML-KEM specific optimizations as per [X-Wing], and RSA-KEM specific optimizations since RSA-KEM is a bijective map between ciphertexts and plaintexts.

The general combiner defined in {{I-D.ounsworth-cfrg-kem-combiners}} is:

~~~
Combiner(ct1, ss1, ct2, ss2, fixedInfo) =
Expand All @@ -464,6 +471,11 @@ Each registered composite KEM algorithm must specify the choice of `KDF`, `fixed

See {{sec-cons-kem-combiner}} for further discussion of the security coniserations of this KEM combiner.

However, optimazations may be made in the following ways:
ounsworth marked this conversation as resolved.
Show resolved Hide resolved

* As discussed in {{sec-cons-ct-collision}}, the ML-KEM ciphertext may be safely omited.
* As discussed in {{sec-cons-ct-collision}}, the RSA-KEM ciphertext may be safely omited.


### Named KEM Combiner parameter sets

Expand Down Expand Up @@ -494,15 +506,6 @@ these choices are somewhat arbitrary but aiming to match security level of the i
END EDNOTE


# Example KEM Combiner instantiation

For example, the KEM combiner used with the first entry of {{tab-kem-algs}}, `id-MLKEM512-ECDH-P256-KMAC128` would be:

~~~
Combiner(ct1, ss1, ct2, ss2, "id-MLKEM512-ECDH-P256-KMAC128") =
KMAC128( 0x00000001 || ss_1 || ss_2 ||
"id-MLKEM512-ECDH-P256-KMAC128", 256, "")
~~~


# Algorithm Identifiers {#sec-alg-ids}
Expand All @@ -515,24 +518,21 @@ TODO: OIDs to be replaced by IANA.

Therefore &lt;CompKEM&gt;.1 is equal to 2.16.840.1.114027.80.5.2.1

| KEM Type OID | OID | First Algorithm | Second Algorithm | KEM Combiner |
|--------- | ----------------- | ---------- | ---------- | ---------- |
| id-MLKEM512-ECDH-P256-KMAC128 | &lt;CompKEM&gt;.1 | MLKEM512 | ECDH-P256 | KMAC128/256 |
| id-MLKEM512-ECDH-brainpoolP256r1-KMAC128 | &lt;CompKEM&gt;.2 | MLKEM512 | ECDH-brainpoolp256r1 | KMAC128/256 |
| id-MLKEM512-X25519-KMAC128 | &lt;CompKEM&gt;.3 | MLKEM512 | X25519 | KMAC128/256 |
| id-MLKEM512-RSA2048-KMAC128 | &lt;CompKEM&gt;.13 | MLKEM512 | RSA-KEM 2048 | KMAC128/256 |
| id-MLKEM512-RSA3072-KMAC128 | &lt;CompKEM&gt;.4 | MLKEM512 | RSA-KEM 3072 | KMAC128/256 |
| id-MLKEM768-ECDH-P256-KMAC256 | &lt;CompKEM&gt;.5 | MLKEM768 | ECDH-P256 | KMAC256/384 |
| id-MLKEM768-ECDH-brainpoolP256r1-KMAC256 | &lt;CompKEM&gt;.6 | MLKEM768 | ECDH-brainpoolp256r1 | KMAC256/384 |
| id-MLKEM768-X25519-KMAC256 | &lt;CompKEM&gt;.7 | MLKEM768 | X25519 | KMAC256/384 |
| id-MLKEM1024-ECDH-P384-KMAC256 | &lt;CompKEM&gt;.8 | MLKEM1024 | ECDH-P384 | KMAC256/512 |
| id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 | &lt;CompKEM&gt;.9 | MLKEM1024 | ECDH-brainpoolP384r1 | KMAC256/512 |
| id-MLKEM1024-X448-KMAC256 | &lt;CompKEM&gt;.10 | MLKEM1024 | X448 | KMAC256/512 |
| KEM Type | OID | First Algorithm | Second Algorithm |
|--------- | ----------------- | ---------- | ---------- |
| id-MLKEM512-ECDH-P256-KMAC128 | &lt;CompKEM&gt;.1 | MLKEM512 | ECDH-P256 |
| id-MLKEM512-ECDH-brainpoolP256r1-KMAC128 | &lt;CompKEM&gt;.2 | MLKEM512 | ECDH-brainpoolp256r1 |
| id-MLKEM512-X25519-KMAC128 | &lt;CompKEM&gt;.3 | MLKEM512 | X25519 |
| id-MLKEM512-RSA2048-KMAC128 | &lt;CompKEM&gt;.13 | MLKEM512 | RSA-KEM 2048 |
| id-MLKEM512-RSA3072-KMAC128 | &lt;CompKEM&gt;.4 | MLKEM512 | RSA-KEM 3072 |
| id-MLKEM768-ECDH-P256-KMAC256 | &lt;CompKEM&gt;.5 | MLKEM768 | ECDH-P256 |
| id-MLKEM768-ECDH-brainpoolP256r1-KMAC256 | &lt;CompKEM&gt;.6 | MLKEM768 | ECDH-brainpoolp256r1 |
| id-MLKEM768-X25519-KMAC256 | &lt;CompKEM&gt;.7 | MLKEM768 | X25519 |
| id-MLKEM1024-ECDH-P384-KMAC256 | &lt;CompKEM&gt;.8 | MLKEM1024 | ECDH-P384 |
| id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 | &lt;CompKEM&gt;.9 | MLKEM1024 | ECDH-brainpoolP384r1 |
| id-MLKEM1024-X448-KMAC256 | &lt;CompKEM&gt;.10 | MLKEM1024 | X448 |
{: #tab-kem-algs title="Composite KEM key types"}


The table above contains everything needed to implement the listed explicit composite algorithms, with the exception of some special notes found below in this section. See the ASN.1 module in section {{sec-asn1-module}} for the explicit definitions of the above Composite signature algorithms.

Full specifications for the referenced algorithms can be found as follows:

* _ECDH_: There does not appear to be a single IETF definition of ECDH, so we refer to the following:
Expand All @@ -542,11 +542,52 @@ Full specifications for the referenced algorithms can be found as follows:
* _RSA-KEM_: {{I-D.ietf-lamps-rfc5990bis}}
* _X25519 / X448_: [RFC8410]

Note that all ECDH as well as X25519 and X448 algorithms MUST be promoted into KEMs according to {{I-D.ounsworth-lamps-cms-dhkem}}.

EDNOTE: I believe that [SP.800-56Ar3] and [BSI-ECC] give equivalent and interoperable algorithms, so maybe this is extranuous detail to include?

The "KEM Combiner" column refers to the definitions in {{sec-kem-combiner}}.
The KEM combiners for each algorithm are instantiated as follows

| KEM Combiner Name | KDF | outputBits |
| --- | ------- |--- |
| KMAC128/256 | KMAC128 | 256 |
| KMAC256/384 | KMAC256 | 384 |
| KMAC256/512 | KMAC256 | 512 |
{: #tab-named-kem-combiners title="Named KEM Combiners"}

KMAC is defined in NIST SP 800-185 [SP800-185]. The `KMAC(K, X, L, S)` parameters are instantiated as follows:

* `K`: the ASCI value of the name of the Kem Type.
* `X`: the message input to `KDF()`, as defined above.
* `L`: integer representation of `outputBits`.
* `S`: empty string.

| KEM Type | KEM Combiner | KDF Input X |
|--------- | ---------- | ------------- |
| id-MLKEM512-ECDH-P256-KMAC128 | KMAC128/256 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM512-ECDH-brainpoolP256r1-KMAC128 | KMAC128/256 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM512-X25519-KMAC128 | KMAC128/256 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM512-RSA2048-KMAC128 | KMAC128/256 | ss1 \|\| ss2 |
| id-MLKEM512-RSA3072-KMAC128 | KMAC128/256 | ss1 \|\| ss2 |
| id-MLKEM768-ECDH-P256-KMAC256 | KMAC256/384 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM768-ECDH-brainpoolP256r1-KMAC256 | KMAC256/384 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM768-X25519-KMAC256 | KMAC256/384 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM1024-ECDH-P384-KMAC256 | KMAC256/512 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM1024-ECDH-brainpoolP384r1-KMAC256 | KMAC256/512 | ss1 \|\| ss2 \|\| ct2 |
| id-MLKEM1024-X448-KMAC256 | KMAC256/512 | ss1 \|\| ss2 \|\| ct2 |
{: #tab-kem-combiner-instantiations title="KEM Combiner Instattiations"}


The tables above contains everything needed to implement the listed explicit composite algorithms, with the exception of some special notes found below in this section. See the ASN.1 module in section {{sec-asn1-module}} for the explicit definitions of the above Composite signature algorithms.


## Example KEM Combiner instantiation

For example, the KEM combiner used with the first entry of {{tab-kem-algs}}, `id-MLKEM512-ECDH-P256-KMAC128` would be:

~~~
KMAC128( 0x00000001 || ss_1 || ss_2 || ct2
"id-MLKEM512-ECDH-P256-KMAC128", 256, "")
~~~


## RSA-KEM Parameters

Expand Down Expand Up @@ -670,7 +711,11 @@ This document uses directly the KEM Combiner defined in {{I-D.ounsworth-cfrg-kem
> If both the secret share `ss_i` and the ciphertext `ct_i` are constant length, then k_i MAY be constructed concatenating the two values.
> If `ss_i` or `ct_i` are not guaranteed to have constant length, it is REQUIRED to append the rlen encoded length when concatenating, prior to inclusion in the overall construction.

The component KEMs used in this specification are RSA-KEM {{I-D.ietf-lamps-rfc5990bis}}, ECDH KEM {{I-D.ounsworth-lamps-cms-dhkem}} and ML-KEM {{FIPS.203-ipd}} all of which meet the criteria of having constant-length shared secrets and ciphertexts and therefore we justify using the simpler construction that omits the length tag.
The component KEMs used in this specification are RSA-KEM {{I-D.ietf-lamps-rfc5990bis}}, ECDH, X25519, X448, and ML-KEM {{FIPS.203-ipd}} all of which meet the criteria of having constant-length shared secrets and ciphertexts and therefore we justify using the simpler construction that omits the length tag.

### Ciphertext collision resistance {#sec-cons-ct-collision}

The notion of a ciphertext cellision resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts that will decapsulate to the same shared secret under the same public key. In [X-Wing] it is proven that ML-KEM has this property and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Similarly, RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} is a bijective map between the shared secret `Z` and the ciphertext `C` and so is naturally immune to ciphertext collision. This leaves only ECDH, X25519 and X448 which are not ciphertext collision resistant and for which the ciphertexts need to be included in the derivation of the shared secret.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Similarly, RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} is a bijective map between the shared secret Z and the ciphertext C and so is naturally immune to ciphertext collision. This leaves only ECDH, X25519 and X448 which are not ciphertext collision resistant and for which the ciphertexts need to be included in the derivation of the shared secret.

I am not sure I get that. Why is RSA-KEM in rfc5990bis CCR?

rfc5990bis defines

CEK <-  random 256-bits
z <-$ [0, n);
c <- z^e mod n;
WK <- ENCRYPT(KDF(z), CEK);
CC <- (WK, c)
RSA-ENCAPS(pubkey=(e,n)) :=  (CC, CEK)

Someone that can break c or WK can produce a different CC' which leads to the same CEK by producing a different value of c. ML-KEM did not have that issue because there is only one random m used for the encapsulation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't the definition of CCR that we care about here that you can't have z -> c and z' -> c where z != z' ? Since we're not borrowing the symmetric WRAP primitive from 5990, I don't see why that matters?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm just looking at this now, so apologies if I'm mistaken. But I think the argument that the mapping between RSA ciphertext and plaintext is bijective only holds once you fix the modulus. So I think you would need some binding to the modulus in the KDF input to achieve bijectivity. (But do not take this as a proof that it's okay if you have this -- would need more careful consideration than I've given it so far.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To err on the safe side, this has been changed to:

Ciphertext collision resistance is not guaranteed for either RSA-KEM or ECDH, therefore these ciphertexts are bound to the key derivation.



<!-- End of Security Considerations section -->
Expand Down
Loading