diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 61a4d2a..44baa11 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -395,53 +395,8 @@ The KEM interface was chosen as the interface for a composite key establishment This specification uses the Post-Quantum KEM ML-KEM as specified in [FIPS.203] and {{I-D.ietf-lamps-kyber-certificates}}. For Traditional KEMs, this document uses the RSA-OAEP algorithm defined in [RFC8017], the Elliptic Curve Diffie-Hellman key agreement schemes ECDH defined in section 5.7.1.2 of [SP.800-56Ar3], and X25519 / X448 which are defined in [RFC8410]. A combiner function is used to combine the two component shared secrets into a single shared secret. -# Composite ML-KEM Functions - -## Key Generation - -To generate a new keypair for Composite schemes, the `KeyGen() -> (pk, sk)` function is used. The KeyGen() function calls the two key generation functions of the component algorithms for the Composite keypair in no particular order. Multi-process or multi-threaded applications might choose to execute the key generation functions in parallel for better key generation performance. - -The following process is used to generate composite keypair values: - -~~~ -KeyGen() -> (pk, sk) - -Explicit Inputs: - None - -Implicit Input: - ML-KEM A placeholder for the specific ML-KEM algorithm and - parameter set to use, for example, could be "ML-KEM-65". - - Trad A placeholder for the specific traditional algorithm and - parameter set to use, for example "RSA-OAEP" - or "X25519". - -Output: - (pk, sk) The composite keypair. -Function KeyGen(): - - (mldsaPK, mldsaSK) <- ML-DSA.KeyGen() - (tradPK, tradSK) <- Trad.KeyGen() - - if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK): - // Component key generation failure - output "Key generation error" - - pk <- CompositeSignaturePublicKey(mldsaPK, tradPK) - sk <- CompositeSignaturePrivateKey(mldsaSK, tradSK) - - return (pk, sk) - -~~~ -{: #alg-composite-keygen title="Composite KeyGen(pk, sk)"} - -The structures CompositeSignaturePublicKey and CompositeSignaturePrivateKey are described in {{sec-composite-pub-keys}} and {{sec-priv-key}} respectively. - -In order to ensure fresh keys, the key generation functions MUST be executed for both component algorithms. Compliant parties MUST NOT use or import component keys that are used in other contexts, combinations, or by themselves as keys for standalone algorithm use. - -### Promotion of RSA-OAEP into a KEM {#sec-RSAOAEPKEM} +## Promotion of RSA-OAEP into a KEM {#sec-RSAOAEPKEM} The RSA Optimal Asymmetric Encryption Padding (OAEP), as defined in section 7.1 of [RFC8017] is a public key encryption algorithm used to transport key material from a sender to a receiver. It is promoted into a KEM by having the sender generate a random 256 bit secret and encrypt it. @@ -469,11 +424,9 @@ RSAOAEPKEM.Decap(skR, enc): ~~~ -Note that, at least at the time of writing, the algorithm `RSAOAEPKEM` is not defined as a standalone algorithm within PKIX standards and it does not have an assigned algorithm OID, so it connot be used directly with CMS KEMRecipientInfo [RFC9629]; it is merely a building block for the composite algorithm. - -### Promotion of ECDH into a KEM {#sec-DHKEM} +## Promotion of ECDH into a KEM {#sec-DHKEM} -An elliptic curve Diffie-Hellman key agreement is promoted into a KEM `Encap(pk) -> (ss, ct)` using a simplified version of the DHKEM definition from [RFC9180]. +An elliptic curve Diffie-Hellman key agreement is promoted into a KEM `Encap(pk) -> (ss, ct)` using a simplified version of the DHKEM definition from [RFC9180]; simplified to remove the context-binding labels since the shared secret output by the overall Composite ML-KEM already binds a composite domain separator, so there is no need to also utilize labels within DHKEM. Note that, at least at the time of writing, the algorithm `DHKEM` is not defined as a standalone algorithm within PKIX standards and it does not have an assigned algorithm OID, so it connot be used directly with CMS KEMRecipientInfo [RFC9629]; it is merely a building block for the composite algorithm. @@ -502,6 +455,54 @@ This construction applies for all variants of elliptic curve Diffie-Hellman used The simplifications from the DHKEM definition in [RFC9180] is that since the ciphertext and receiver's public key are included explicitly in the Composite ML-KEM combiner, there is no need to construct the `kem_context` object, and since a domain separator is included explicitly in the Composite ML-KEM combiner there is no need to perform the labelled steps of `ExtractAndExpand()`. + +# Composite ML-KEM Functions + +## Key Generation + +To generate a new keypair for Composite schemes, the `KeyGen() -> (pk, sk)` function is used. The KeyGen() function calls the two key generation functions of the component algorithms for the Composite keypair in no particular order. Multi-process or multi-threaded applications might choose to execute the key generation functions in parallel for better key generation performance. + +The following process is used to generate composite keypair values: + +~~~ +KeyGen() -> (pk, sk) + +Explicit Inputs: + None + +Implicit Input: + ML-KEM A placeholder for the specific ML-KEM algorithm and + parameter set to use, for example, could be "ML-KEM-65". + + Trad A placeholder for the specific traditional algorithm and + parameter set to use, for example "RSA-OAEP" + or "X25519". + +Output: + (pk, sk) The composite keypair. + +Function KeyGen(): + + (mldsaPK, mldsaSK) <- ML-DSA.KeyGen() + (tradPK, tradSK) <- Trad.KeyGen() + + if NOT (mldsaPK, mldsaSK) or NOT (tradPK, tradSK): + // Component key generation failure + output "Key generation error" + + pk <- CompositeSignaturePublicKey(mldsaPK, tradPK) + sk <- CompositeSignaturePrivateKey(mldsaSK, tradSK) + + return (pk, sk) + +~~~ +{: #alg-composite-keygen title="Composite KeyGen(pk, sk)"} + +The structures CompositeSignaturePublicKey and CompositeSignaturePrivateKey are described in {{sec-composite-pub-keys}} and {{sec-priv-key}} respectively. + +In order to ensure fresh keys, the key generation functions MUST be executed for both component algorithms. Compliant parties MUST NOT use or import component keys that are used in other contexts, combinations, or by themselves as keys for standalone algorithm use. + + ### KEM Combiner {#sec-kem-combiner} 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 probability.