From 2cbe4bbf8a867e73267c76f11f038eaf2a86437c Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 5 Aug 2024 19:34:04 -0500 Subject: [PATCH 01/22] Private key requires public key. Closes #50 --- draft-ietf-lamps-pq-composite-kem.md | 21 +++++++-------------- 1 file changed, 7 insertions(+), 14 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 65c2ecb..8acd27f 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -221,8 +221,12 @@ This document introduces a set of Key Encapsulation Mechanism (KEM) schemes that # Changes in version -05 +Interop-affecting changes: + * Fixed a bug in the definition of the Encaps() functions: KEMs, according to both RFC9180 and FIPS 203 should always return (ss, ct), but we had (ct, ss). +Editorial changes: + Still to do in a future version: @@ -500,7 +504,7 @@ The parameters field MUST be absent. The order of the component keys is the same as the order defined in {{sec-composite-pub-keys}} for the components of CompositeKEMPublicKey. -When a `CompositePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MAY be present in the CompositeKEMPrivateKey. +When a `CompositePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where multiple `OneAsymmetricKey`s are nested inside an outer `OneAsymmetricKey`, which the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MUST be present in the CompositeKEMPrivateKey. The reason for requiring component public keys to be carried with the private keys is discussed in {{impl-cons-decaps-pubkey}} In some use-cases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see {{sec-fips}} for more discussion. The establishment of correspondence between public keys in a CompositeKEMPublicKey and private keys not represented in a single composite structure is beyond the scope of this document. @@ -930,20 +934,9 @@ The term "ease of migration" is used here to mean that existing systems can be g These migration and interoperability concerns need to be thought about in the context of various types of protocols that make use of X.509 and PKIX with relation to key establishment and content encryption, from online negotiated protocols such as TLS 1.3 [RFC8446] and IKEv2 [RFC7296], to non-negotiated asynchronous protocols such as S/MIME signed email [RFC8551], as well as myriad other standardized and proprietary protocols and applications that leverage CMS [RFC5652] encrypted structures. +## Decapsulation Requires the Public Key {#impl-cons-decaps-pubkey} -### Parallel PKIs - -EDNOTE: remove this section? - -We present the term "Parallel PKI" to refer to the setup where a PKI end entity possesses two or more distinct public keys or certificates for the same identity (name), but containing keys for different cryptographic algorithms. One could imagine a set of parallel PKIs where an existing PKI using legacy algorithms (RSA, ECC) is left operational during the post-quantum migration but is shadowed by one or more parallel PKIs using pure post quantum algorithms or composite algorithms (legacy and post-quantum). - -Equipped with a set of parallel public keys in this way, a client would have the flexibility to choose which public key(s) or certificate(s) to use in a given signature operation. - -For negotiated protocols, the client could choose which public key(s) or certificate(s) to use based on the negotiated algorithms. - -For non-negotiated protocols, the details for obtaining backwards compatibility will vary by protocol, but for example in CMS [RFC5652]. - -EDNOTE: I copied and pruned this text from I-D.ounsworth-pq-composite-sigs. It probably needs to be fleshed out more as we better understand the implementation concerns around composite encryption. +ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS203-ipd]. Additionally, in order to achaive the public-key binding property the KEM combiner used to form the composite KEM requires the public key as input to the KDF that derives the output shared secret. One way to carry the public key would be to include each component's public key within the respective OneAsymmetricKey as is required by the private key encoding given in {{sec-priv-key}}. Implementers who choose a different private key encoding MUST consider how to private the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoparable composite private key format given in this document in {{sec-priv-key}} requires the component public keys to be included. From a31873d9360453cf6044315e48ed05a2a629cce5 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 5 Aug 2024 19:35:50 -0500 Subject: [PATCH 02/22] Private key requires public key. Closes #50 --- draft-ietf-lamps-pq-composite-kem.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 8acd27f..42e735f 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -224,9 +224,11 @@ This document introduces a set of Key Encapsulation Mechanism (KEM) schemes that Interop-affecting changes: * Fixed a bug in the definition of the Encaps() functions: KEMs, according to both RFC9180 and FIPS 203 should always return (ss, ct), but we had (ct, ss). +* Interoperable composite private key format requires component public keys (because public keys are required for decapsulation) Editorial changes: +* Added an Implementation Consideration section explaining why private keys need to contain the public keys. Still to do in a future version: From 1907c2ded1bc4e0ffd294169f64aa494b683fd7f Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Tue, 6 Aug 2024 08:25:34 -0500 Subject: [PATCH 03/22] Private key requires public key only for traditional component. Thanks Bas. Closes #50 --- draft-ietf-lamps-pq-composite-kem.md | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 42e735f..f56cfc8 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -506,7 +506,7 @@ The parameters field MUST be absent. The order of the component keys is the same as the order defined in {{sec-composite-pub-keys}} for the components of CompositeKEMPublicKey. -When a `CompositePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where multiple `OneAsymmetricKey`s are nested inside an outer `OneAsymmetricKey`, which the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. Associated public key material MUST be present in the CompositeKEMPrivateKey. The reason for requiring component public keys to be carried with the private keys is discussed in {{impl-cons-decaps-pubkey}} +When a `CompositePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where multiple `OneAsymmetricKey`s are nested inside an outer `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. In some use-cases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see {{sec-fips}} for more discussion. The establishment of correspondence between public keys in a CompositeKEMPublicKey and private keys not represented in a single composite structure is beyond the scope of this document. @@ -938,7 +938,10 @@ These migration and interoperability concerns need to be thought about in the co ## Decapsulation Requires the Public Key {#impl-cons-decaps-pubkey} -ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS203-ipd]. Additionally, in order to achaive the public-key binding property the KEM combiner used to form the composite KEM requires the public key as input to the KDF that derives the output shared secret. One way to carry the public key would be to include each component's public key within the respective OneAsymmetricKey as is required by the private key encoding given in {{sec-priv-key}}. Implementers who choose a different private key encoding MUST consider how to private the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoparable composite private key format given in this document in {{sec-priv-key}} requires the component public keys to be included. +ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS203-ipd], and for this reason the private key encoding specified in FIPS 203 includes the public key. Therefore it is not required to carry it in the `OneAsymmetricKey.publicKey` field, which remains optional, but is strictly speaking redundant since an ML-KEM public key can be parsed from an ML-KEM private key, and thus populating the `OneAsymmetricKey.publicKey` field would mean that two copies of the public key data are transmitted. + + +With regard to the traditional algorithms, RSA or Elliptic CUrve, in order to achieve the public-key binding property the KEM combiner used to form the composite KEM, the combiner requires the traditional public key as input to the KDF that derives the output shared secret. Therefore it is required to carry the public key within the respective `OneAsymmetricKey.publicKey` as per the private key encoding given in {{sec-priv-key}}. Implementers who choose to use a different private key encoding than the one specified in this document MUST consider how to provide the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoparable composite private key format given in this document in {{sec-priv-key}} requires the public key of the traditional component to be included. From 78fc9c78aba7edec69118e409de2f0cb9319b108 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 10 Aug 2024 10:36:03 -0500 Subject: [PATCH 04/22] Clarify the SHA3 OIDs to use for the CMS section. Closes #43 --- draft-ietf-lamps-pq-composite-kem.md | 29 ++++++++++++++++------------ 1 file changed, 17 insertions(+), 12 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index f56cfc8..f5167df 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -651,6 +651,9 @@ Full specifications for the referenced algorithms can be found as follows: * _ML-KEM_: {{I-D.ietf-lamps-kyber-certificates}} and [FIPS.203-ipd] * _RSA-OAEP_: [RFC3560] * _X25519 / X448_: [RFC8410] +* SHA3 is defined in SHA3: [FIPS 202]. + +Note that OIDs are not required for the KDF and hash functions do not need OIDs since they are used inline and are not referenced by any AlgorithIDs. EDNOTE: I believe that [SP.800-56Ar3] and [BSI-ECC] give equivalent and inter-operable algorithms, so maybe this is extraneous detail to include? @@ -721,24 +724,26 @@ The following table lists the REQUIRED KDF and key-encryption algorithms to pres | Composite KEM OID | KDF | Key Encryption Alg | |--------- | --- | --- | -| id-MLKEM512-ECDH-P256 | SHA3-256 | id-aes128-Wrap | -| id-MLKEM512-ECDH-brainpoolP256r1 | SHA3-256 | id-aes128-Wrap | -| id-MLKEM512-X25519 | SHA3-256 | id-aes128-Wrap | -| id-MLKEM512-RSA2048 | SHA3-256 | id-aes128-Wrap | -| id-MLKEM512-RSA3072 | SHA3-256 | id-aes128-Wrap | -| id-MLKEM768-ECDH-P256 | SHA3-384 | id-aes256-Wrap | -| id-MLKEM768-ECDH-brainpoolP256r1 | SHA3-384 | id-aes256-Wrap | -| id-MLKEM768-X25519 | SHA3-384 | id-aes256-Wrap | -| id-MLKEM1024-ECDH-P384 | SHA3-512 | id-aes256-Wrap | -| id-MLKEM1024-ECDH-brainpoolP384r1 | SHA3-512 | id-aes256-Wrap | -| id-MLKEM1024-X448 | SHA3-512 | id-aes256-Wrap | +| id-MLKEM512-ECDH-P256 | id-sha3-256 | id-aes128-Wrap | +| id-MLKEM512-ECDH-brainpoolP256r1 | id-sha3-256 | id-aes128-Wrap | +| id-MLKEM512-X25519 | id-sha3-256 | id-aes128-Wrap | +| id-MLKEM512-RSA2048 | id-sha3-256 | id-aes128-Wrap | +| id-MLKEM512-RSA3072 | id-sha3-256 | id-aes128-Wrap | +| id-MLKEM768-ECDH-P256 | id-sha3-384 | id-aes256-Wrap | +| id-MLKEM768-ECDH-brainpoolP256r1 | id-sha3-384 | id-aes256-Wrap | +| id-MLKEM768-X25519 | id-sha3-384 | id-aes256-Wrap | +| id-MLKEM1024-ECDH-P384 | id-sha3-512 | id-aes256-Wrap | +| id-MLKEM1024-ECDH-brainpoolP384r1 | id-sha3-512 | id-aes256-Wrap | +| id-MLKEM1024-X448 | id-sha3-512 | id-aes256-Wrap | {: #tab-cms-kdf-wrap title="REQUIRED pairings for CMS KDF and WRAP"} +In all cases above, the hash function used as a KDF produces a longer output than needed by the encryption algorithm, so the output should simply be truncated to the correct length -- ie use the leftmost significant bits. + Note: `id-aes256-Wrap` is stronger than necessary for the MLKEM768 combinations at the NIST level 3 192 bit security level, however `id-aes256-Wrap` was chosen because it has better general adoption than `id-aes192-Wrap`. where: -* SHA3-* KDF instantiations are defined in {{I-D.ietf-lamps-cms-sha3-hash}}. +* `id-sha3-*` KDF instantiations are defined in {{I-D.ietf-lamps-cms-sha3-hash}}. * `id-aes*-Wrap` are defined in [RFC3394]. From d9c7b8654e593473d9060587a281e7c697d15359 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 10 Aug 2024 10:43:02 -0500 Subject: [PATCH 05/22] Update Acknowledgements. Closes #44 --- draft-ietf-lamps-pq-composite-kem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index f5167df..de510a0 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -965,7 +965,7 @@ EDNOTE TODO: Check with Max Pala whether this IPR actually applies to this draft This document incorporates contributions and comments from a large group of experts. The Editors would especially like to acknowledge the expertise and tireless dedication of the following people, who attended many long meetings and generated millions of bytes of electronic mail and VOIP traffic over the past year in pursuit of this document: -Serge Mister (Entrust), Ali Noman (Entrust), and +Serge Mister (Entrust), Ali Noman (Entrust), Peter C. (UK NCSC), Sophie Schmieg (Google), Deirdre Connolly (SandboxAQ), Falko Strenzke (MTG AG), Dan van Geest (Crypto Next), Piotr Popis (Enigma), and Douglas Stebila (University of Waterloo). We are grateful to all, including any contributors who may have From 055b1c5a5ea133ba363b86905c9f1c17ba24fc44 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 11:39:45 -0500 Subject: [PATCH 06/22] Specified that the tradCT and tradPK inputs to the KEM combiner must be the raw values without the OCTET STRING wrapper. Closes #49 --- draft-ietf-lamps-pq-composite-kem.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index de510a0..f86579a 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -224,7 +224,8 @@ This document introduces a set of Key Encapsulation Mechanism (KEM) schemes that Interop-affecting changes: * Fixed a bug in the definition of the Encaps() functions: KEMs, according to both RFC9180 and FIPS 203 should always return (ss, ct), but we had (ct, ss). -* Interoperable composite private key format requires component public keys (because public keys are required for decapsulation) +* Interoperable composite private key format requires component public keys (because public keys are required for decapsulation). +* Specified that the tradCT and tradPK inputs to the KEM combiner must be the raw values without the OCTET STRING wrapper. Editorial changes: @@ -588,8 +589,8 @@ where: * `counter` SHALL be the fixed 32-bit value `0x00000001` which is placed here solely for the purposes of compliance with [SP.800-56Cr2]. * `tradSS` is the shared secret from the traditional component (elliptic curve or RSA). * `mlkemSS` is the shared secret from the ML-KEM componont. -* `tradCT` is the ciphertext from the traditional component (elliptic curve or RSA). -* `tradPK` is the public key of the traditional component (elliptic curve or RSA). +* `tradCT` is the ciphertext from the traditional component (elliptic curve or RSA). This MUST be the raw value of the ciphertext without the DER OCTET STRING wrapping. The intention is to maximize implementation reuse with other protocols that are not ASN.1-based. +* `tradPK` is the public key of the traditional component (elliptic curve or RSA). This MUST be the raw value of the SubjectPublicKeyInfo.publicKey without the DER OCTET STRING wrapping. The intention is to maximize implementation reuse with other protocols that are not ASN.1-based. * `domSep` SHALL be the DER encoded value of the object identifier of the composite KEM algorithm as listed in {{sec-domain}}. * `||` represents concatenation. From 6347be9634428f17105600868caf4963c79d9fc9 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 11:43:33 -0500 Subject: [PATCH 07/22] TODO: Update this once the on-list discussion settles. --- draft-ietf-lamps-pq-composite-kem.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index f86579a..ea0612c 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -873,6 +873,8 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ ## Component Algorithm Selection Criteria {#sec-selection-criteria} +TODO: Update this once the on-list discussion settles. + The composite algorithm combinations defined in this document were chosen according to the following guidelines: 1. RSA combinations are provided at key sizes of 2048 and 3072 bits. Since RSA 2048 and 3072 are considered to have 112 and 128 bits of classical security respectively, they are both matched with NIST PQC Level 1 algorithms and 128-bit symmetric algorithms. From 10d82c01b2c31d1aa93978731c31a2e811a37346 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 12:11:01 -0500 Subject: [PATCH 08/22] Added a security consideration about key reuse. Closes #38 --- draft-ietf-lamps-pq-composite-kem.md | 33 ++++++++++++++++++---------- 1 file changed, 22 insertions(+), 11 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index ea0612c..ed53309 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -491,6 +491,8 @@ Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects cor When the CompositeKEMPublicKey must be provided in octet string or bit string format, the data structure is encoded as specified in {{sec-encoding-rules}}. +In order to maintain security properties of the composite, applications that use composite keys MUST always perform fresh key generations of both component keys and MUST NOT reuse existing key material. See {{sec-cons-key-reuse}} for a discussion. + ## CompositeKEMPrivateKey {#sec-priv-key} @@ -871,6 +873,26 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ # Security Considerations + +## KEM Combiner Security Analysis {#sec-cons-kem-combiner} + +TODO + +EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combiners and X-Wing discussion. If CFRG doesn't move fast enough for us, then we may need to leverage this security consideration directly on top of the X-Wing paper [X-Wing]. + + +### Ciphertext collision resistance {#sec-cons-ct-collision} + +The notion of a ciphertext collision 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. Ciphertext collision resistance is not guaranteed for either RSA-OAEP or ECDH, therefore these ciphertexts are bound to the key derivation. + +### Key Reuse {#sec-cons-key-reuse} + +TODO: does this section actually apply to composite KEMs, or only to composite signatures? + +When using single-algorithm cryptography, the best practice is to always generate fresh key material for each purpose, for example when renewing a certificate, or obtaining both a TLS and S/MIME certificate for the same device, however in practice key reuse in such scenarios is often not catestrophic to security and therefore often tolerated. With composite keys we have a much stricter security requirement. However this reasoning does not hold in the composite setting. Consider an RSA key which already appears within a certificate and which is already being used to sign documents. If a composite key is created which combines this existing RSA key with an ML-DSA key then an attacker is free to remove the ML-DSA component of any message signed with this key and instead present the document as if it had only been signed by the RSA key. The scope of such "stripping attacks" is greatly reduced if composite keys never share key material with non-composite keys. While this logic is less straight-forward for encryption operations involving KEM keys, it does apply to authentication modes involving KEMs. A similar argument applies for two composite keys which share one component but not the other; as an example it becomes difficult for CAs and other relying parties to detect if a composite key contains a key which has been revoked due to key compromise since needing to keep lists of individual component keys is more complex than being able to search such lists for the composite key as a whole. + +For these reasons, applications using composite keys MUST perform fresh key generations for both components. Failure to do so negates any non-separability properties {{TODO-cite-draft-hale-connolly-signature-spectrums}} of the composite and effectively reduces it to a + ## Component Algorithm Selection Criteria {#sec-selection-criteria} TODO: Update this once the on-list discussion settles. @@ -896,17 +918,6 @@ Since composite algorithms are registered independently of their component algor The composite KEM design specified in this document, and especially that of the KEM combiner specified in {{sec-kem-combiner}} means that the overall composite KEM algorithm should be considered to have the security strength of the strongest of its component algorithms; ie as long as one component algorithm remains strong, then the overall composite algorithm remains strong. -## KEM Combiner Security Analysis {#sec-cons-kem-combiner} - -TODO - -EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combiners and X-Wing discussion. If CFRG doesn't move fast enough for us, then we may need to leverage this security consideration directly on top of the X-Wing paper [X-Wing]. - - -### Ciphertext collision resistance {#sec-cons-ct-collision} - -The notion of a ciphertext collision 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. Ciphertext collision resistance is not guaranteed for either RSA-OAEP or ECDH, therefore these ciphertexts are bound to the key derivation. - From c95fce17488384947f8c8049bd0695abbe975e55 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 12:15:02 -0500 Subject: [PATCH 09/22] Added a security consideration about key reuse. Closes #38 --- draft-ietf-lamps-pq-composite-kem.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index ed53309..64598bb 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -230,6 +230,10 @@ Interop-affecting changes: Editorial changes: * Added an Implementation Consideration section explaining why private keys need to contain the public keys. +* Added a security consideration about key reuse. + + + Still to do in a future version: From 24c009c164222ad1ba6ff6555c26396b9816d6c3 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 12:43:50 -0500 Subject: [PATCH 10/22] Added security considerations about SHA3-vs-HKDF-SHA2 and a warning against generifying this construction to other combinations of ciphers. Relates to #42 --- draft-ietf-lamps-pq-composite-kem.md | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 64598bb..3c24a7f 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -231,6 +231,7 @@ Editorial changes: * Added an Implementation Consideration section explaining why private keys need to contain the public keys. * Added a security consideration about key reuse. +* Added security considerations about SHA3-vs-HKDF-SHA2 and a warning against generifying this construction to other combinations of ciphers. @@ -887,7 +888,19 @@ EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combin ### Ciphertext collision resistance {#sec-cons-ct-collision} -The notion of a ciphertext collision 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. Ciphertext collision resistance is not guaranteed for either RSA-OAEP or ECDH, therefore these ciphertexts are bound to the key derivation. +The notion of a ciphertext collision 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. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. + +However, since ciphertext collision resistance is not guaranteed at all, even in a correct implementation, for either RSA-OAEP or ECDH, these ciphertexts are bound to the key derivation. + +### SHA3 vs HKDF-SHA2 + +The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2. In order to achieve this, KDF used in the KEM combiner needs to possess collision, pre-image, and second pre-image resistance with regard to each of its inputs independently, property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. + +SHA3 is known to have all of the necessary dual-PRF properties CITATION NEEDED, but SHA2 does not CITATION NEEDED and therefore all SHA2-based constructions MUST use SHA2 within a Hash-based Key Derivation Function (HKDF-SHA2). + +### Generifying this construction + +It should be cleart that the security analsis of the presented KEM combiner construction relies heavily on the specific choices of component algorithms and combiner KDF, and this combiner construction SHOULD NOT by applied to any other combination of ciphers without performing the appropriate security analysis. ### Key Reuse {#sec-cons-key-reuse} From 09f68c068e76ea5b361cd6c5ca98c7cb80607d61 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 24 Aug 2024 15:17:23 -0500 Subject: [PATCH 11/22] Added security considerations about SHA3-vs-HKDF-SHA2 and a warning against generifying this construction to other combinations of ciphers. Relates to #42 --- draft-ietf-lamps-pq-composite-kem.md | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 3c24a7f..ddff995 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -881,20 +881,21 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ ## KEM Combiner Security Analysis {#sec-cons-kem-combiner} -TODO - EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combiners and X-Wing discussion. If CFRG doesn't move fast enough for us, then we may need to leverage this security consideration directly on top of the X-Wing paper [X-Wing]. +The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2. Additionally, we also need to consider the case where one of the component algorithms is completely broken; that the private key is known to an attacker, or worse that the public key, private key, and ciphertext are maniputaled by the attacker. In this case, we rely on the construction of the KEM combiner to ensure that the value of the other shared secret cannot be leaked or the combined shared secret predicted via manipulation of the broken algorithm. The following sections continue this discussion. ### Ciphertext collision resistance {#sec-cons-ct-collision} -The notion of a ciphertext collision 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. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. +The notion of a ciphertext collision resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts `c != c'` that will decapsulate to the same shared secret under the same public key. For the purposes of a hybrid KEM combiner, this property means that given two composite ciphertexts `(c1, c2)` and `(c1', c2')`, we must obtain a unique overall shared secret so long as either `c1 != c1'` or `c2 != c2'` -- i.e. the overall composite KEM is ciphertext collision resistant, and therefore IND-CCA2 secure so, long as one of the component KEMs is. + +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. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. -However, since ciphertext collision resistance is not guaranteed at all, even in a correct implementation, for either RSA-OAEP or ECDH, these ciphertexts are bound to the key derivation. +However, since neither RSA-OAEP or ECDH do not guarantee ciphertext collision resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring ciphertext collision resistance to the overall composite KEM. ### SHA3 vs HKDF-SHA2 -The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2. In order to achieve this, KDF used in the KEM combiner needs to possess collision, pre-image, and second pre-image resistance with regard to each of its inputs independently, property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. +In order to achieve this, KDF used in the KEM combiner needs to possess collision, pre-image, and second pre-image resistance with regard to each of its inputs independently, property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. SHA3 is known to have all of the necessary dual-PRF properties CITATION NEEDED, but SHA2 does not CITATION NEEDED and therefore all SHA2-based constructions MUST use SHA2 within a Hash-based Key Derivation Function (HKDF-SHA2). From 4ff648e551d1b888478b56b532c4e4a1de8b74a7 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 26 Aug 2024 11:43:56 -0500 Subject: [PATCH 12/22] Tweaks and spell check --- draft-ietf-lamps-pq-composite-kem.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index ddff995..4dfe592 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -885,13 +885,13 @@ EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combin The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2. Additionally, we also need to consider the case where one of the component algorithms is completely broken; that the private key is known to an attacker, or worse that the public key, private key, and ciphertext are maniputaled by the attacker. In this case, we rely on the construction of the KEM combiner to ensure that the value of the other shared secret cannot be leaked or the combined shared secret predicted via manipulation of the broken algorithm. The following sections continue this discussion. -### Ciphertext collision resistance {#sec-cons-ct-collision} +### Second pre-image resistance {#sec-cons-ct-collision} -The notion of a ciphertext collision resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts `c != c'` that will decapsulate to the same shared secret under the same public key. For the purposes of a hybrid KEM combiner, this property means that given two composite ciphertexts `(c1, c2)` and `(c1', c2')`, we must obtain a unique overall shared secret so long as either `c1 != c1'` or `c2 != c2'` -- i.e. the overall composite KEM is ciphertext collision resistant, and therefore IND-CCA2 secure so, long as one of the component KEMs is. +The notion of a second pre-image resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts `c != c'` that will decapsulate to the same shared secret under the same public key. For the purposes of a hybrid KEM combiner, this property means that given two composite ciphertexts `(c1, c2)` and `(c1', c2')`, we must obtain a unique overall shared secret so long as either `c1 != c1'` or `c2 != c2'` -- i.e. the overall composite KEM is second pre-image resistant, and therefore IND-CCA2 secure so, long as one of the component KEMs is. -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. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. +In [X-Wing] it is proven that ML-KEM is a ciphertext property and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. -However, since neither RSA-OAEP or ECDH do not guarantee ciphertext collision resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring ciphertext collision resistance to the overall composite KEM. +However, since neither RSA-OAEP or ECDH do not guarantee second pre-image resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring second pre-image resistance to the overall composite KEM. ### SHA3 vs HKDF-SHA2 From d3214ba9f68221027dd79a6bbbe96d614a6b8128 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Mon, 26 Aug 2024 13:50:31 -0500 Subject: [PATCH 13/22] Added reference to GHP18. Relates to #42 --- draft-ietf-lamps-pq-composite-kem.md | 29 ++++++++++++++++++---------- 1 file changed, 19 insertions(+), 10 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 4dfe592..6134d13 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -156,7 +156,8 @@ informative: RFC8551: RFC9180: I-D.draft-ietf-tls-hybrid-design-04: - I-D.draft-driscoll-pqt-hybrid-terminology-01: + I-D.draft-ietf-pquip-pqt-hybrid-terminology-03: + I-D.draft-ietf-pquip-hybrid-signature-spectrums-00: I-D.draft-ietf-lamps-kyber-certificates-01: I-D.draft-housley-lamps-cms-kemri-02: X-Wing: @@ -208,6 +209,14 @@ informative: - ins: A. Roginksy name: Allan Reginsky org: National Institute of Standards and Technology (NIST) + GHP18: + title: KEM Combiners + author: + name: Federico Giacon + name: Felix Heuer + name: Bertram Poettering + date: 2018 + target: https://eprint.iacr.org/2018/024 --- abstract @@ -248,7 +257,7 @@ The advent of quantum computing poses a significant threat to current cryptograp Unlike previous migrations between cryptographic algorithms, the decision of when to migrate and which algorithms to adopt is far from straightforward. Even after the migration period, it may be advantageous for an entity's cryptographic identity to incorporate multiple public-key algorithms to enhance security. -Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.driscoll-pqt-hybrid-terminology}}. +Cautious implementers may opt to combine cryptographic algorithms in such a way that an attacker would need to break all of them simultaneously to compromise the protected data. These mechanisms are referred to as Post-Quantum/Traditional (PQ/T) Hybrids {{I-D.ietf-pquip-pqt-hybrid-terminology}}. Certain jurisdictions are already recommending or mandating that PQC lattice schemes be used exclusively within a PQ/T hybrid framework. The use of Composite scheme provides a straightforward implementation of hybrid solutions compatible with (and advocated by) some governments and cybersecurity agencies [BSI2021]. @@ -275,7 +284,7 @@ This document is intended for general applicability anywhere that key establishm ## Terminology {#sec-terminology} 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 from {{I-D.driscoll-pqt-hybrid-terminology}}. +This document is consistent with all terminology from {{I-D.ietf-pquip-pqt-hybrid-terminology}}. In addition, the following terms are used in this document: **COMBINER:** @@ -299,7 +308,7 @@ In addition, the following terms are used in this document: ## Composite Design Philosophy -{{I-D.driscoll-pqt-hybrid-terminology}} defines composites as: +{{I-D.ietf-pquip-pqt-hybrid-terminology}} defines composites as: > *Composite Cryptographic Element*: A cryptographic element that > incorporates multiple component cryptographic elements of the same @@ -883,21 +892,21 @@ EDNOTE to IANA: OIDs will need to be replaced in both the ASN.1 module and in {{ EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combiners and X-Wing discussion. If CFRG doesn't move fast enough for us, then we may need to leverage this security consideration directly on top of the X-Wing paper [X-Wing]. -The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2. Additionally, we also need to consider the case where one of the component algorithms is completely broken; that the private key is known to an attacker, or worse that the public key, private key, and ciphertext are maniputaled by the attacker. In this case, we rely on the construction of the KEM combiner to ensure that the value of the other shared secret cannot be leaked or the combined shared secret predicted via manipulation of the broken algorithm. The following sections continue this discussion. +The primary security property of the KEM combiner is that it preserves IND-CCA2 of the overall composite KEM so long as at least one component is IND-CCA2 [X-Wing] [GHP18]. Additionally, we also need to consider the case where one of the component algorithms is completely broken; that the private key is known to an attacker, or worse that the public key, private key, and ciphertext are maniputaled by the attacker. In this case, we rely on the construction of the KEM combiner to ensure that the value of the other shared secret cannot be leaked or the combined shared secret predicted via manipulation of the broken algorithm. The following sections continue this discussion. -### Second pre-image resistance {#sec-cons-ct-collision} +### Second pre-image resistance of componet KEMs {#sec-cons-ct-collision} The notion of a second pre-image resistant KEM is defined in [X-Wing] being the property that it is computationally difficult to find two different ciphertexts `c != c'` that will decapsulate to the same shared secret under the same public key. For the purposes of a hybrid KEM combiner, this property means that given two composite ciphertexts `(c1, c2)` and `(c1', c2')`, we must obtain a unique overall shared secret so long as either `c1 != c1'` or `c2 != c2'` -- i.e. the overall composite KEM is second pre-image resistant, and therefore IND-CCA2 secure so, long as one of the component KEMs is. -In [X-Wing] it is proven that ML-KEM is a ciphertext property and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. +In [X-Wing] it is proven that ML-KEM is a second pre-image resistant KEM and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. However, since neither RSA-OAEP or ECDH do not guarantee second pre-image resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring second pre-image resistance to the overall composite KEM. ### SHA3 vs HKDF-SHA2 -In order to achieve this, KDF used in the KEM combiner needs to possess collision, pre-image, and second pre-image resistance with regard to each of its inputs independently, property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. +In order to achieve the desired secutiy property that the composite KEM is IND-CCA2 whenever at least one of the component KEMs is, the KDF used in the KEM combiner needs to possess collision and second pre-image resistance with respect to each of its inputs independently; a property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. -SHA3 is known to have all of the necessary dual-PRF properties CITATION NEEDED, but SHA2 does not CITATION NEEDED and therefore all SHA2-based constructions MUST use SHA2 within a Hash-based Key Derivation Function (HKDF-SHA2). +SHA3 is known to have all of the necessary dual-PRF properties [X-Wing], but SHA2 does not and therefore all SHA2-based constructions MUST use SHA2 within an HMAC construction such as HKDF-SHA2 [GHP18]. ### Generifying this construction @@ -909,7 +918,7 @@ TODO: does this section actually apply to composite KEMs, or only to composite s When using single-algorithm cryptography, the best practice is to always generate fresh key material for each purpose, for example when renewing a certificate, or obtaining both a TLS and S/MIME certificate for the same device, however in practice key reuse in such scenarios is often not catestrophic to security and therefore often tolerated. With composite keys we have a much stricter security requirement. However this reasoning does not hold in the composite setting. Consider an RSA key which already appears within a certificate and which is already being used to sign documents. If a composite key is created which combines this existing RSA key with an ML-DSA key then an attacker is free to remove the ML-DSA component of any message signed with this key and instead present the document as if it had only been signed by the RSA key. The scope of such "stripping attacks" is greatly reduced if composite keys never share key material with non-composite keys. While this logic is less straight-forward for encryption operations involving KEM keys, it does apply to authentication modes involving KEMs. A similar argument applies for two composite keys which share one component but not the other; as an example it becomes difficult for CAs and other relying parties to detect if a composite key contains a key which has been revoked due to key compromise since needing to keep lists of individual component keys is more complex than being able to search such lists for the composite key as a whole. -For these reasons, applications using composite keys MUST perform fresh key generations for both components. Failure to do so negates any non-separability properties {{TODO-cite-draft-hale-connolly-signature-spectrums}} of the composite and effectively reduces it to a +For these reasons, applications using composite keys MUST perform fresh key generations for both components. Failure to do so negates any non-separability properties {{I-D.ietf-pquip-hybrid-signature-spectrums}} of the composite and effectively reduces it to a ## Component Algorithm Selection Criteria {#sec-selection-criteria} From fadc34152277fc82054d2b6ee7e4d51d26863355 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sun, 8 Sep 2024 14:33:58 -0500 Subject: [PATCH 14/22] Added statement on ML-KEM applicability --- draft-ietf-lamps-pq-composite-kem.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 6134d13..ff973b7 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -221,7 +221,7 @@ informative: --- abstract -This document introduces a set of Key Encapsulation Mechanism (KEM) schemes that use pairs of cryptographic elements such as public keys and cipher texts to combine their security properties. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS data structures and protocols. This document defines eleven specific pairwise combinations, namely ML-KEM Composite Schemes, that blend ML-KEM with traditional algorithms such as RSA-OAEP, ECDH, X25519, and X448. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in {{I-D.housley-lamps-cms-kemri}}. These combinations are tailored to meet security best practices and regulatory requirements. +This document introduces a set of Key Encapsulation Mechanism (KEM) schemes that use pairs of cryptographic elements such as public keys and cipher texts to combine their security properties. These schemes effectively mitigate risks associated with the adoption of post-quantum cryptography and are fully compatible with existing X.509, PKIX, and CMS data structures and protocols. This document defines eleven specific pairwise combinations, namely ML-KEM Composite Schemes, that blend ML-KEM with traditional algorithms such as RSA-OAEP, ECDH, X25519, and X448. For use within CMS, this document is intended to be coupled with the CMS KEMRecipientInfo mechanism in {{I-D.housley-lamps-cms-kemri}}. These combinations are tailored to meet security best practices and regulatory requirements. Composite ML-KEM is applicable in any application that would otherwise use ML-KEM, but wants the protection against breaks or catastrophic bugs in ML-KEM. @@ -278,7 +278,9 @@ PQ/T Hybrid cryptography can, in general, provide solutions to two migration pro This document defines a specific instantiation of the PQ/T Hybrid paradigm called "composite" where multiple cryptographic algorithms are combined to form a single key encapsulation mechanism (KEM) key and ciphertext such that they can be treated as a single atomic algorithm at the protocol level. Composite algorithms address algorithm strength uncertainty because the composite algorithm remains strong so long as one of its components remains strong. Concrete instantiations of composite KEM algorithms are provided based on ML-KEM, RSA-OAEP and ECDH. Backwards compatibility is not directly covered in this document, but is the subject of {{sec-backwards-compat}}. -This document is intended for general applicability anywhere that key establishment or enveloped content encryption is used within PKIX or CMS structures. +Composite ML-KEM is intended for general applicability anywhere that key establishment or enveloped content encryption is used within PKIX or CMS structures. + + ## Terminology {#sec-terminology} From e1202d80a4e9e5ed41dcf51a5e3fddfb298b1772 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Thu, 12 Sep 2024 17:22:29 -0500 Subject: [PATCH 15/22] Editorial comments from Piotr. Closes #46 --- draft-ietf-lamps-pq-composite-kem.md | 18 +++++------------- 1 file changed, 5 insertions(+), 13 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index ff973b7..d6ac3e2 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -341,7 +341,7 @@ The KEM interface was chosen as the interface for a composite key establishment ### Composite KeyGen -The `KeyGen() -> (pk, sk)` of a composite KEM algorithm will perform the `KeyGen()` of the respective component KEM algorithms and it produces a composite public key `pk` as per {{sec-composite-pub-keys}} and a composite secret key `sk` is per {{sec-priv-key}}. +The `KeyGen() -> (pk, sk)` of a composite KEM algorithm will perform the `KeyGen()` of the respective component KEM algorithms and it produces a composite public key `pk` as per {{sec-composite-pub-keys}} and a composite secret key `sk` as per {{sec-priv-key}}. ~~~ CompositeKEM.KeyGen(): @@ -366,7 +366,7 @@ RSAOAEPKEM.Encaps(pkR): `Decaps(sk, ct) -> ss` is accomplished in the analogous way. ~~~ -RSAKEM.Decap(skR, enc): +RSAOAEPKEM.Decap(skR, enc): shared_secret = RSA-OAEP.Decrypt(skR, enc) return shared_secret @@ -501,7 +501,7 @@ CompositeKEMPublicKey ::= SEQUENCE SIZE (2) OF BIT STRING {: artwork-name="CompositeKEMPublicKey-asn.1-structures"} -A composite key MUST contain two component public keys. The order of the component keys is determined by the definition of the corresponding algorithm identifier as defined in section {{sec-alg-ids}}. +A composite key MUST contain two component public keys as SEQUENCE of two bit strings. The order of the component keys is determined by the definition of the corresponding algorithm identifier as defined in section {{sec-alg-ids}}. Some applications may need to reconstruct the `SubjectPublicKeyInfo` objects corresponding to each component public key. {{tab-kem-algs}} in {{sec-alg-ids}} provides the necessary mapping between composite and their component algorithms for doing this reconstruction. This also motivates the design choice of `SEQUENCE OF BIT STRING` instead of `SEQUENCE OF OCTET STRING`; using `BIT STRING` allows for easier transcription between CompositeKEMPublicKey and SubjectPublicKeyInfo. @@ -578,7 +578,7 @@ kema-CompositeKEM { ## CompositeCiphertextValue {#sec-CompositeCiphertextValue} -The compositeCipherTextValue is a concatenation of the ciphertexts of the +The compositeCipherTextValue is a SEQUENCE of the ciphertexts of the underlying component algorithms. It is represented in ASN.1 as follows: ~~~ @@ -634,8 +634,6 @@ where: * `T = mlkemSS`, and * `FixedInfo = tradCT || tradPK || domSep`. -In the case that KDF is KMAC, the message to be hashed MUST be post-pended with `H_outputBits` and the byte string `01001011 || 01000100 || 01000110`, which represents the sequence of characters “K”, “D,” and “F” in 8-bit ASCII, as required by [SP.800-56Cr2] section 4.1 Option 3. `salt` is left empty since KMAC is only required to behave as a hash function and not as a keyed MAC. - # Algorithm Identifiers {#sec-alg-ids} @@ -732,13 +730,7 @@ Composite KEM algorithms MAY be employed for one or more recipients in the CMS e ## Underlying Components -A CMS implementation that supports a composite KEM algorithm MUST support at least the following underlying components: - -When a particular Composite KEM OID is supported, an implementation MUST support the corresponding KDF algorithm identifier in {{tab-cms-kdf-wrap}}. - -When a particular Composite KEM OID is supported, an implementation MUST support the corresponding key-encryption algorithm identifier in {{tab-cms-kdf-wrap}}. - -The following table lists the REQUIRED KDF and key-encryption algorithms to preserve security and performance characteristics of each composite algorithm. +When a particular Composite KEM OID is supported, a CMS implementation MUST support the corresponding KDF and key-encryption algorithms listed in {{tab-cms-kdf-wrap}}, which have been chosen to preserve security and performance characteristics of each composite algorithm. | Composite KEM OID | KDF | Key Encryption Alg | From abc3f018fb7d9207b21e35469aec465f0aac8a13 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Thu, 26 Sep 2024 10:51:03 -0500 Subject: [PATCH 16/22] PR comments from Jan --- draft-ietf-lamps-pq-composite-kem.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index d6ac3e2..450747f 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -156,7 +156,7 @@ informative: RFC8551: RFC9180: I-D.draft-ietf-tls-hybrid-design-04: - I-D.draft-ietf-pquip-pqt-hybrid-terminology-03: + I-D.draft-ietf-pquip-pqt-hybrid-terminology-04: I-D.draft-ietf-pquip-hybrid-signature-spectrums-00: I-D.draft-ietf-lamps-kyber-certificates-01: I-D.draft-housley-lamps-cms-kemri-02: @@ -748,7 +748,7 @@ When a particular Composite KEM OID is supported, a CMS implementation MUST supp | id-MLKEM1024-X448 | id-sha3-512 | id-aes256-Wrap | {: #tab-cms-kdf-wrap title="REQUIRED pairings for CMS KDF and WRAP"} -In all cases above, the hash function used as a KDF produces a longer output than needed by the encryption algorithm, so the output should simply be truncated to the correct length -- ie use the leftmost significant bits. +In all cases above, the hash function used as a KDF produces a longer output than needed by the encryption algorithm, so the output SHALL be truncated to the correct length -- ie the leftmost significant bits are used. Note: `id-aes256-Wrap` is stronger than necessary for the MLKEM768 combinations at the NIST level 3 192 bit security level, however `id-aes256-Wrap` was chosen because it has better general adoption than `id-aes192-Wrap`. @@ -981,7 +981,7 @@ These migration and interoperability concerns need to be thought about in the co ML-KEM always requires the public key in order to perform various steps of the Fujisaki-Okamoto decapsulation [FIPS203-ipd], and for this reason the private key encoding specified in FIPS 203 includes the public key. Therefore it is not required to carry it in the `OneAsymmetricKey.publicKey` field, which remains optional, but is strictly speaking redundant since an ML-KEM public key can be parsed from an ML-KEM private key, and thus populating the `OneAsymmetricKey.publicKey` field would mean that two copies of the public key data are transmitted. -With regard to the traditional algorithms, RSA or Elliptic CUrve, in order to achieve the public-key binding property the KEM combiner used to form the composite KEM, the combiner requires the traditional public key as input to the KDF that derives the output shared secret. Therefore it is required to carry the public key within the respective `OneAsymmetricKey.publicKey` as per the private key encoding given in {{sec-priv-key}}. Implementers who choose to use a different private key encoding than the one specified in this document MUST consider how to provide the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoparable composite private key format given in this document in {{sec-priv-key}} requires the public key of the traditional component to be included. +With regard to the traditional algorithms, RSA or Elliptic Curve, in order to achieve the public-key binding property the KEM combiner used to form the composite KEM, the combiner requires the traditional public key as input to the KDF that derives the output shared secret. Therefore it is required to carry the public key within the respective `OneAsymmetricKey.publicKey` as per the private key encoding given in {{sec-priv-key}}. Implementers who choose to use a different private key encoding than the one specified in this document MUST consider how to provide the component public keys to the decapsulate routine. While some implementations might contain routines to computationally derive the public key from the private key, it is not guaranteed that all implementations will support this; for this reason the interoparable composite private key format given in this document in {{sec-priv-key}} requires the public key of the traditional component to be included. From bab59c714df4c80c6c564350482021f0eb53b4bc Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Thu, 26 Sep 2024 12:31:18 -0500 Subject: [PATCH 17/22] Removing the Algorithm Selection Criteria section. Closes #63 --- draft-ietf-lamps-pq-composite-kem.md | 13 ------------- 1 file changed, 13 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 450747f..852e618 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -914,19 +914,6 @@ When using single-algorithm cryptography, the best practice is to always generat For these reasons, applications using composite keys MUST perform fresh key generations for both components. Failure to do so negates any non-separability properties {{I-D.ietf-pquip-hybrid-signature-spectrums}} of the composite and effectively reduces it to a -## Component Algorithm Selection Criteria {#sec-selection-criteria} - -TODO: Update this once the on-list discussion settles. - -The composite algorithm combinations defined in this document were chosen according to the following guidelines: - -1. RSA combinations are provided at key sizes of 2048 and 3072 bits. Since RSA 2048 and 3072 are considered to have 112 and 128 bits of classical security respectively, they are both matched with NIST PQC Level 1 algorithms and 128-bit symmetric algorithms. -1. Elliptic curve algorithms are provided with combinations on each of the NIST [RFC6090], Brainpool [RFC5639], and Edwards [RFC7748] curves. NIST PQC Levels 1 - 3 algorithms are matched with 256-bit curves, while NIST levels 4 - 5 are matched with 384-bit elliptic curves. This provides a balance between matching classical security levels of post-quantum and traditional algorithms, and also selecting elliptic curves which already have wide adoption. -1. NIST level 1 candidates are provided, matched with 256-bit elliptic curves, intended for constrained use cases. - -If other combinations are needed, a separate specification should be submitted to the IETF LAMPS working group. To ease implementation, these specifications are encouraged to follow the construction pattern of the algorithms specified in this document. - -The composite structures defined in this specification allow only for pairs of algorithms. This also does not preclude future specification from extending these structures to define combinations with three or more components. ## Policy for Deprecated and Acceptable Algorithms From 369d158bb8976586c7f09f363531451119993cd5 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Thu, 26 Sep 2024 16:09:40 -0500 Subject: [PATCH 18/22] Minor typo --- draft-ietf-lamps-pq-composite-kem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 852e618..77d4386 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -519,7 +519,7 @@ CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey ~~~ {: artwork-name="CompositeKEMPrivateKey-asn.1-structures"} -Each element is a `OneAsymmetricKey`` [RFC5958] object for a component private key. +Each element is a `OneAsymmetricKey` [RFC5958] object for a component private key. The parameters field MUST be absent. From b39c91b2cc8520124c37b23fb29870a07f1d8401 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Fri, 27 Sep 2024 09:37:04 -0500 Subject: [PATCH 19/22] Clarified AlgIDs for component private keys. Closes #72 --- draft-ietf-lamps-pq-composite-kem.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 77d4386..0a1872a 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -525,7 +525,7 @@ The parameters field MUST be absent. The order of the component keys is the same as the order defined in {{sec-composite-pub-keys}} for the components of CompositeKEMPublicKey. -When a `CompositePrivateKey` is conveyed inside a OneAsymmetricKey structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where multiple `OneAsymmetricKey`s are nested inside an outer `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the privateKeyAlgorithm field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. +Often, a `CompositePrivateKey` will be carried within a carrier format such as PKCS#8 which is itself a `OneAsymmetricKey` structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where we have `CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey` inside another `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the `privateKeyAlgorithm` field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. The `AlgorithmID`s to place into the component `OneAsymmetricKey`s is ambiguous; since `OneAsymmetricKey.PrivateKeyAlgorithmIdentifier.AlgorithmID` is not optional, parsers MUST place something here and producers MAY either duplicate the composite AlgorithmID into beth components, or MAY place the AlgoritmID of the component algorithm, parsers SHOULD ignore the component private key `AlgorithmID`s and assume that the private keys are in the same order as specified in {{tab-kem-algs}}. In some use-cases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see {{sec-fips}} for more discussion. The establishment of correspondence between public keys in a CompositeKEMPublicKey and private keys not represented in a single composite structure is beyond the scope of this document. From e58c67cc8fd45e7023a2941b4eb7503ab926103c Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 28 Sep 2024 10:22:23 -0500 Subject: [PATCH 20/22] Clarified AlgIDs for component private keys. Closes #55 --- draft-ietf-lamps-pq-composite-kem.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 0a1872a..108d202 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -525,7 +525,7 @@ The parameters field MUST be absent. The order of the component keys is the same as the order defined in {{sec-composite-pub-keys}} for the components of CompositeKEMPublicKey. -Often, a `CompositePrivateKey` will be carried within a carrier format such as PKCS#8 which is itself a `OneAsymmetricKey` structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where we have `CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey` inside another `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the `privateKeyAlgorithm` field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the privateKey field SHALL contain the CompositeKEMPrivateKey, and the publicKey field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. The `AlgorithmID`s to place into the component `OneAsymmetricKey`s is ambiguous; since `OneAsymmetricKey.PrivateKeyAlgorithmIdentifier.AlgorithmID` is not optional, parsers MUST place something here and producers MAY either duplicate the composite AlgorithmID into beth components, or MAY place the AlgoritmID of the component algorithm, parsers SHOULD ignore the component private key `AlgorithmID`s and assume that the private keys are in the same order as specified in {{tab-kem-algs}}. +Often, a `CompositePrivateKey` will be carried within a carrier format such as PKCS#8 which is itself a `OneAsymmetricKey` structure (version 1 of which is also known as PrivateKeyInfo) [RFC5958], then a situation arises where we have `CompositeKEMPrivateKey ::= SEQUENCE SIZE (2) OF OneAsymmetricKey` inside another `OneAsymmetricKey`. On the outer `OneAsymmetricKey`, the `privateKeyAlgorithm` field SHALL be set to the corresponding composite algorithm identifier defined according to {{sec-alg-ids}}, the `privateKey` field SHALL contain the `CompositeKEMPrivateKey`, and the `publicKey` field MUST NOT be present. As discussed in {{impl-cons-decaps-pubkey}}, the ML-KEM private key encoding already includes a copy of the public key, so the `publicKey` field of the first `OneAsymmetricKey` remains OPTIONAL. However, the public key of the traditional component, RSA or Elliptic Curve, is required as input to the KEM Combiner function, and is not typically carried within an RSA or Elliptic Curve private key. Therefore the `publicKey` field of the second `OneAsymmetricKey` MUST contain the corresponding public key. See {{impl-cons-decaps-pubkey}} for more discussion. Which `AlgorithmID`s to place into the component `OneAsymmetricKey`s is ambiguous; since `OneAsymmetricKey.PrivateKeyAlgorithmIdentifier.AlgorithmID` is not optional, producers MUST place something here and MAY either duplicate the composite AlgorithmID into both components, or MAY place the AlgorithmID of the component algorithm. Parsers SHOULD ignore the component private key `AlgorithmID`s and assume that the private keys are in the same order as specified in {{tab-kem-algs}}. In some use-cases the private keys that comprise a composite key may not be represented in a single structure or even be contained in a single cryptographic module; for example if one component is within the FIPS boundary of a cryptographic module and the other is not; see {{sec-fips}} for more discussion. The establishment of correspondence between public keys in a CompositeKEMPublicKey and private keys not represented in a single composite structure is beyond the scope of this document. @@ -894,7 +894,7 @@ The notion of a second pre-image resistant KEM is defined in [X-Wing] being the In [X-Wing] it is proven that ML-KEM is a second pre-image resistant KEM and therefore the ML-KEM ciphertext can safely be omitted from the KEM combiner. Note that this makes a fundamental assumption on ML-KEM remaining ciphertext second pre-image resistant, and thefore this formulation of KEM combiner does not fully protect against implementation errors in the ML-KEM component -- particularly around the ciphertext check step of the Fujisaki-Okamoto transform -- which could trivially lead to second ciphertext pre-image attacks that break the IND-CCA2 security of the ML-KEM component and of the overall composite KEM. This could be more fully mitigated by binding the ML-KEM ciphertext in the combiner, but a design decision was made to settle for protection against algorithmic attacks and not implementation attacks against ML-KEM in order to increase performance. -However, since neither RSA-OAEP or ECDH do not guarantee second pre-image resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring second pre-image resistance to the overall composite KEM. +However, since neither RSA-OAEP nor ECDH guarantee second pre-image resistance at all, even in a correct implementation, these ciphertexts are bound to the key derivation in order to guarantee that `c != c'` will yield a unique ciphertext, and thus restoring second pre-image resistance to the overall composite KEM. ### SHA3 vs HKDF-SHA2 From 4ef68bd23a3934ffbbdce0aac8d8d0d7ebf642b8 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 28 Sep 2024 10:46:33 -0500 Subject: [PATCH 21/22] Clarified AlgIDs for component private keys. --- draft-ietf-lamps-pq-composite-kem.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 108d202..63e0c41 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -215,8 +215,18 @@ informative: name: Federico Giacon name: Felix Heuer name: Bertram Poettering - date: 2018 - target: https://eprint.iacr.org/2018/024 + date: 2018 + target: https://eprint.iacr.org/2018/024 + Aviram22: + title: "Practical (Post-Quantum) Key Combiners from One-Wayness and Applications to TLS" + author: + name: Nimrod Aviram + name: Benjamin Dowling + name: Ilan Komargodski + name: Kenneth G. Paterson + name: Eyal Ronen + name: Eylon Yogev + target: https://eprint.iacr.org/2022/065 --- abstract @@ -898,7 +908,7 @@ However, since neither RSA-OAEP nor ECDH guarantee second pre-image resistance a ### SHA3 vs HKDF-SHA2 -In order to achieve the desired secutiy property that the composite KEM is IND-CCA2 whenever at least one of the component KEMs is, the KDF used in the KEM combiner needs to possess collision and second pre-image resistance with respect to each of its inputs independently; a property sometimes called "dual-PRF". Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. +In order to achieve the desired secutiy property that the composite KEM is IND-CCA2 whenever at least one of the component KEMs is, the KDF used in the KEM combiner needs to possess collision and second pre-image resistance with respect to each of its inputs independently; a property sometimes called "dual-PRF" [Aviram22]. Collision and second-pre-image resistance protects against compromise of one component algorithm from resulting in the ability to construct multiple different ciphertexts which result in the same shared secret. Pre-image resistance protects against compromise of one component algorithm being used to attack and learn the value of the other shared secret. SHA3 is known to have all of the necessary dual-PRF properties [X-Wing], but SHA2 does not and therefore all SHA2-based constructions MUST use SHA2 within an HMAC construction such as HKDF-SHA2 [GHP18]. From fe3fa56fa8a22b4a82fcc5062656ba893a6c6e50 Mon Sep 17 00:00:00 2001 From: Mike Ounsworth Date: Sat, 28 Sep 2024 11:54:13 -0500 Subject: [PATCH 22/22] Merged from main --- draft-ietf-lamps-pq-composite-kem.md | 14 -------------- 1 file changed, 14 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md index 04a2e45..5662095 100644 --- a/draft-ietf-lamps-pq-composite-kem.md +++ b/draft-ietf-lamps-pq-composite-kem.md @@ -962,20 +962,6 @@ Since composite algorithms are registered independently of their component algor The composite KEM design specified in this document, and especially that of the KEM combiner specified in {{sec-kem-combiner}} means that the overall composite KEM algorithm should be considered to have the security strength of the strongest of its component algorithms; ie as long as one component algorithm remains strong, then the overall composite algorithm remains strong. -## KEM Combiner Security Analysis {#sec-cons-kem-combiner} - -TODO - -TODO: SHA3 is a dual PRF cite: x-wing - -EDNOTE: the exact text to put here depends on the outcome of the CFRG KEM Combiners and X-Wing discussion. If CFRG doesn't move fast enough for us, then we may need to leverage this security consideration directly on top of the X-Wing paper [X-Wing]. - - -### Ciphertext collision resistance {#sec-cons-ct-collision} - -The notion of a ciphertext collision 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. Ciphertext collision resistance is not guaranteed for either RSA-OAEP or ECDH, therefore these ciphertexts are bound to the key derivation. - - --- back