Merge pull request #8 from lamps-wg/john_integration

John integration branch
lamps-wg · Oct 24, 2023 · d6a1ebd · d6a1ebd
2 parents 945a58d + 746c0b1
commit d6a1ebd
Show file tree

Hide file tree

Showing 2 changed files with 59 additions and 75 deletions.
diff --git a/Composite-KEM-2023.asn b/Composite-KEM-2023.asn
@@ -9,7 +9,7 @@ EXPORTS ALL;
 
 IMPORTS
 
-PUBLIC-KEY, SIGNATURE-ALGORITHM, ParamOptions, AlgorithmIdentifier{}
+PUBLIC-KEY, AlgorithmIdentifier{}
   FROM AlgorithmInformation-2009  -- RFC 5912 [X509ASN1]
       { iso(1) identified-organization(3) dod(6) internet(1)
         security(5) mechanisms(5) pkix(7) id-mod(0)
@@ -102,22 +102,6 @@ kema-CompositeKEM {
 -- Composite KEM Algorithms
 --
 
--- TODO: OID to be replaced by IANA
-id-MLKEM512-RSA2048-KMAC128 OBJECT IDENTIFIER ::= {
-  joint-iso-itu-t(2) country(16) us(840) organization(1) 
-  entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 13 }
-
-pk-MLKEM512-RSA2048-KMAC128 PUBLIC-KEY ::= 
-  pk-CompositeKEM { 
-    id-MLKEM512-RSA2048-KMAC128, 
-    OCTET STRING, RSAPublicKey }
-
-kema-MLKEM512-RSA2048-KMAC128 KEM-ALGORITHM ::= 
-    kema-CompositeKEM{
-      id-MLKEM512-RSA2048-KMAC128, 
-      pk-MLKEM512-RSA2048-KMAC128 }
-
-
 
 -- TODO: OID to be replaced by IANA
 id-MLKEM512-ECDH-P256-KMAC128 OBJECT IDENTIFIER ::= {
@@ -170,19 +154,36 @@ kema-MLKEM512-X25519-KMAC128 KEM-ALGORITHM ::=
 
 
 -- TODO: OID to be replaced by IANA
-id-MLKEM768-RSA3072-KMAC256 OBJECT IDENTIFIER ::= {
+id-MLKEM512-RSA2048-KMAC128 OBJECT IDENTIFIER ::= {
+  joint-iso-itu-t(2) country(16) us(840) organization(1) 
+  entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 13 }
+
+pk-MLKEM512-RSA2048-KMAC128 PUBLIC-KEY ::= 
+  pk-CompositeKEM { 
+    id-MLKEM512-RSA2048-KMAC128, 
+    OCTET STRING, RSAPublicKey }
+
+kema-MLKEM512-RSA2048-KMAC128 KEM-ALGORITHM ::= 
+    kema-CompositeKEM{
+      id-MLKEM512-RSA2048-KMAC128, 
+      pk-MLKEM512-RSA2048-KMAC128 }
+
+
+
+-- TODO: OID to be replaced by IANA
+id-MLKEM512-RSA3072-KMAC128 OBJECT IDENTIFIER ::= {
   joint-iso-itu-t(2) country(16) us(840) organization(1) 
   entrust(114027) algorithm(80) explicitcomposite(5) kem(2) 4 }
 
-pk-MLKEM768-RSA3072-KMAC256 PUBLIC-KEY ::= 
+pk-MLKEM512-RSA3072-KMAC128 PUBLIC-KEY ::= 
   pk-CompositeKEM {
-    id-MLKEM768-RSA3072-KMAC256, 
+    id-MLKEM512-RSA3072-KMAC128, 
     OCTET STRING, RSAPublicKey }
 
-kema-MLKEM768-RSA3072-KMAC256 KEM-ALGORITHM ::=
+kema-MLKEM512-RSA3072-KMAC128 KEM-ALGORITHM ::=
     kema-CompositeKEM{
-      id-MLKEM768-RSA3072-KMAC256, 
-      pk-MLKEM768-RSA3072-KMAC256 }
+      id-MLKEM512-RSA3072-KMAC128, 
+      pk-MLKEM512-RSA3072-KMAC128 }
 
 
 -- TODO: OID to be replaced by IANA
@@ -281,4 +282,4 @@ kema-MLKEM1024-X448-KMAC256 KEM-ALGORITHM ::=
       id-MLKEM1024-X448-KMAC256, 
       pk-MLKEM1024-X448-KMAC256 }
 
-END
+END
diff --git a/draft-ietf-lamps-pq-composite-kem.md b/draft-ietf-lamps-pq-composite-kem.md
@@ -146,7 +146,7 @@ This document assumes that all component algorithms are KEMs, and therefore it d
 
 --- middle
 
-# Changes in version -01
+# Changes in version -01 and -02
 
 Changes affecting interoperability:
 
@@ -156,7 +156,7 @@ Changes affecting interoperability:
   * 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.
+* 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.
@@ -173,11 +173,6 @@ Editorial changes:
 * Made a proper IANA Considerations section.
 * Rename "Kyber" to "ML-KEM".
 
-TODO:
-
-  `[ ]` Oops. KEM Combiner is actually NOT -04. Sync that.
-
-
 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.
@@ -279,13 +274,13 @@ Encaps(pk):
 
   # combine
   ct = CompositeCiphertextValue(ct1, ct2)
-  ss = Combiner(ss1, ss2, algName)
+  ss = Combiner(ct1, ss1, ct2, ss2, algName)
 
   return (ct, ss)
 ~~~
 {: #alg-composite-encaps title="Composite Encaps(pk)"}
 
-where `Combiner(k1, k2, fixedInfo)` is defined in {{sec-kem-combiner}} and `CompositeCiphertextValue` is defined in {{sec-CompositeCiphertextValue}}.
+where `Combiner(ct1, ss1, ct2, ss2, fixedInfo)` is defined in {{sec-kem-combiner}} and `CompositeCiphertextValue` is defined in {{sec-CompositeCiphertextValue}}.
 
 ### Composite Decaps
 
@@ -302,20 +297,20 @@ Decaps(sk, ct):
   ss2 = ComponentKEM2.Encaps(sk2, ct2)
 
   # combine
-  ss = Combiner(ss1, ss2, algName)
+  ss = Combiner(ct1, ss1, ct2, ss2, algName)
 
   return ss
 ~~~
 {: #alg-composite-decaps title="Composite Decaps(sk, ct)"}
 
-where `Combiner(k1, k2, fixedInfo)` is defined in {sec-kem-combiner}.
+where `Combiner(ct1, ss1, ct2, ss2, fixedInfo)` is defined in {sec-kem-combiner}.
 
 
 ## Component Algorithm Selection Criteria {#sec-selection-criteria}
 
 The composite algorithm combinations defined in this document were chosen according to the following guidelines:
 
-1. A single RSA combination is provided at a key size of 3072 bits, matched with NIST PQC Level 3 algorithms.
+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.
 
@@ -453,8 +448,8 @@ TODO: as per https://www.enisa.europa.eu/publications/post-quantum-cryptography-
 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:
 
 ~~~
-Combiner(ss1, ss2, fixedInfo) = KDF(counter || ss1 || ss2 || fixedInfo,
-                                      outputBits)
+Combiner(ct1, ss1, ct2, ss2, fixedInfo) =
+  KDF(counter || ct1 || ss1 || ct2 || ss2 || fixedInfo, outputBits)
 ~~~
 {: #code-generic-kem-combiner title="Generic KEM combiner construction"}
 
@@ -465,10 +460,14 @@ where:
 * `counter` SHALL be the fixed 32-bit value `0x00000001` which is placed here soly for the purposes of easy compliance with [SP.800-56Cr2].
 * `||` represents concatenation.
 
-Each registered composite KEM algorithm must specify the exact KEM combiner construction that is to be used.
+Each registered composite KEM algorithm must specify the choice of `KDF`, `fixedInfo`, and `outputBits` to be used.
+
+See {{sec-cons-kem-combiner}} for further discussion of the security coniserations of this KEM combiner.
 
 
-This specification uses the following KMAC-based instantiations of the generic KEM combiner:
+### Named KEM Combiner parameter sets
+
+This specification references KEM combiner instantiations according to the following names:
 
 | KEM Combiner Name | KDF     | outputBits |
 | ---               | ------- |---         |
@@ -495,10 +494,12 @@ 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(ss1, ss2, "id-MLKEM512-ECDH-P256-KMAC128") =
+Combiner(ct1, ss1, ct2, ss2, "id-MLKEM512-ECDH-P256-KMAC128") =
            KMAC128( 0x00000001 || ss_1 || ss_2 ||
               "id-MLKEM512-ECDH-P256-KMAC128", 256, "")
 ~~~
@@ -516,11 +517,11 @@ 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-RSA2048-KMAC128               | &lt;CompKEM&gt;.13 | MLKEM512        | RSA-KEM 2048     | KMAC128/256  |
 | 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-MLKEM768-RSA3072-KMAC256               | &lt;CompKEM&gt;.4  | MLKEM768        | RSA-KEM 3072     | KMAC256/384 |
+| 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 |
@@ -547,50 +548,24 @@ EDNOTE: I believe that [SP.800-56Ar3] and [BSI-ECC] give equivalent and interope
 
 The "KEM Combiner" column refers to the definitions in {{sec-kem-combiner}}.
 
-## id-MLKEM512-RSA2048-KMAC128 Parameters
+## RSA-KEM Parameters
 
-Use of RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} requires additional specification.
+Use of RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} within `id-MLKEM512-RSA2048-KMAC128` and `id-MLKEM512-RSA3072-KMAC128` requires additional specification.
 
-The RSA component keys MUST be generated at the 2048-bit security level in order to match security level with ML-KEM-768.
+The RSA component keys MUST be generated at the 2048-bit and 3072-bit security level respectively.
 
-As with the other composite KEM algorithms, when `id-MLKEM512-RSA2048-KMAC128` is used in an AlgorithmIdentifier, the parameters MUST be absent. `id-MLKEM512-RSA2048-KMAC128` SHALL instantiate RSA-KEM with the following parameters:
+As with the other composite KEM algorithms, when `id-MLKEM512-RSA2048-KMAC128` or `id-MLKEM512-RSA3072-KMAC128` is used in an AlgorithmIdentifier, the parameters MUST be absent. The RSA-KEM SHALL be instantiated with the following parameters:
 
 | RSA-KEM Parameter          | Value                      |
 | -------------------------- | -------------------------- |
 | keyDerivationFunction      | kda-kdf3 with id-sha3-256  |
 | keyLength                  | 128                        |
-| DataEncapsulationMechanism | kwa-aes128-wrap            |
 {: #rsa-kem-params2048 title="RSA-KEM 2048 Parameters"}
 
 where:
 
 * `kda-kdf3` is defined in {{I-D.ietf-lamps-rfc5990bis}} which references it from [ANS-X9.44].
 * `mda-shake256` is defined in {{I-D.housley-lamps-cms-sha3-hash}}.
-* `kwa-aes128-wrap` is defined in {{I-D.ietf-lamps-rfc5990bis}}
-
-
-
-## id-MLKEM768-RSA3072-KMAC256 Parameters
-
-Use of RSA-KEM {{I-D.ietf-lamps-rfc5990bis}} requires additional specification.
-
-The RSA component keys MUST be generated at the 3072-bit security level in order to match security level with ML-KEM-768.
-
-As with the other composite KEM algorithms, when `id-MLKEM768-RSA3072-KMAC256` is used in an AlgorithmIdentifier, the parameters MUST be absent. `id-MLKEM768-RSA3072-KMAC256` SHALL instantiate RSA-KEM with the following parameters:
-
-| RSA-KEM Parameter          | Value                      |
-| -------------------------- | -------------------------- |
-| keyDerivationFunction      | kda-kdf3 with id-sha3-384  |
-| keyLength                  | 256                        |
-| DataEncapsulationMechanism | kwa-aes256-wrap            |
-{: #rsa-kem-params3072 title="RSA-KEM 3072 Parameters"}
-
-where:
-
-* `kda-kdf3` is defined in {{I-D.ietf-lamps-rfc5990bis}} which references it from [ANS-X9.44].
-* `mda-shake256` is defined in {{I-D.housley-lamps-cms-sha3-hash}}.
-* `kwa-aes256-wrap` is defined in {{I-D.ietf-lamps-rfc5990bis}}
-
 
 
 # ASN.1 Module {#sec-asn1-module}
@@ -686,9 +661,17 @@ 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
+## KEM Combiner {#sec-cons-kem-combiner}
+
+This document uses directly the KEM Combiner defined in {{I-D.ounsworth-cfrg-kem-combiners}} and therefore IND-CCA2 of any of its ingredient KEMs, i.e. the newly formed combined KEM is IND-CCA2 secure as long as at least one of the ingredient KEMs is
+
+{{I-D.ounsworth-cfrg-kem-combiners}} provides two different constructions depending on the properties of the component KEMs:
+
+> 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.
 
-This document uses directly the KEM Combiner defined in {{I-D.ounsworth-cfrg-kem-combiners}} and therefore inherits all of its security considerations, which the authors believe have all been addressed by the concrete instantiations of KEM algorithms and combiner parameters specified in this document.
 
 <!-- End of Security Considerations section -->