From fc71f981735de48b787a75d6b6e237c49bd9c21a Mon Sep 17 00:00:00 2001 From: ID Bot Date: Wed, 29 Jan 2025 19:10:25 +0000 Subject: [PATCH] Script updating gh-pages from eecf979. [ci skip] --- draft-ietf-lamps-pq-composite-kem.html | 42 +++++++++++------- draft-ietf-lamps-pq-composite-kem.txt | 61 ++++++++++++++++---------- index.html | 2 +- 3 files changed, 65 insertions(+), 40 deletions(-) diff --git a/draft-ietf-lamps-pq-composite-kem.html b/draft-ietf-lamps-pq-composite-kem.html index 51cd91a..5e9fe8b 100644 --- a/draft-ietf-lamps-pq-composite-kem.html +++ b/draft-ietf-lamps-pq-composite-kem.html @@ -1275,10 +1275,10 @@

4. Encode the ciphertext - ct = mlkemCT || tradCT + ct = mlkemCT || tradCT 5. Combine the KEM secrets and additional context to yield the composite shared secret - - ss = KDF(mlkemSS || tradSS || tradCT || tradPK || Domain) + if KDF is "SHA3-256" + ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Domain) + else if KDF is "HKDF" + ss = HKDF-Extract(salt="", IKM=mlkemSS || tradSS || tradCT || tradPK || Domain) + # Note: salt is the empty string (0 octets), which will internally be mapped + # to the zero vector `0x00..00` of the correct input size for the underlying + # hash function as per [RFC 5869]. 6. Output composite shared secret key and ciphertext @@ -1846,7 +1851,13 @@

5. Combine the KEM secrets and additional context to yield the composite shared secret - ss = KDF(mlkemSS || tradSS || tradCT || tradPK || Domain) + if KDF is "SHA3-256" + ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Domain) + else if KDF is "HKDF" + ss = HKDF-Extract(salt="", IKM=mlkemSS || tradSS || tradCT || tradPK || Domain) + # Note: salt is the empty string (0 octets), which will internally be mapped + # to the zero vector `0x00..00` of the correct input size for the underlying + # hash function as per [RFC 5869]. 6. Output composite shared secret key @@ -2633,10 +2644,10 @@

Full specifications for the referenced algorithms can be found either further down in this section, or in Appendix B.

Note that here we differ slightly from the internal KDF used within the KEM combiner in Section 7 because [RFC9629] requires that the KDF listed in the KEMRecipientInfo kdf field must have an interface which accepts KDF(IKM, L, info), so here we need to use KMAC and cannot directly use SHA3. Since we require 256-bits of (2nd) pre-image resistance, we use KMAC256 for the Composite ML-KEM algorithms with internally use SHA3-256, as aligned with Table 3 of [SP.800-57pt1r5].

-
+

-8.1.1. Use of the HKDF-based Key Derivation Function +8.1.1. Use of the HKDF-based Key Derivation Function within CMS

The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is defined in [RFC5869].

The HKDF function is a composition of the HKDF-Extract and HKDF-Expand functions.

@@ -2672,10 +2683,10 @@

HKDF may be used with different hash functions, including SHA-256 [FIPS.180-4]. The object identifier id-alg-hkdf-with-sha256 is defined in [RFC8619], and specifies the use of HKDF with SHA-256. The parameter field MUST be absent when this algorithm identifier is used to specify the KDF for ML-KEM in KemRecipientInfo.

-
+

-8.1.2. Use of the KMAC-based Key Derivation Function +8.1.2. Use of the KMAC-based Key Derivation Function within CMS

KMAC256-KDF is a KMAC-based KDF specified for use in CMS in [I-D.ietf-lamps-cms-sha3-hash]. The definition of KMAC is copied here for convenience. Here, KMAC# indicates the use of either KMAC128-KDF or KMAC256-KDF, although only KMAC256 is used in this specification.

KMAC#(K, X, L, S) takes the following parameters:

@@ -3969,9 +3980,8 @@

D.1. FIPS Certification

TODO -- update this once NIST SP 800-227 is published.

-

EDNOTE At time of writing, it is unclear that the KEM combiner presented in this document would pass a FIPS certification. The SHA3 instantiations should pass under SP 800-56Cr2 Option 1, but the HKDF-SHA2 combinations are technically not allowed under SP 800-56Cr2 even though Option 2 allows HMAC-based constructions, but unfortunately only HKDF-Extract is FIPS-allowed, not HKDF-Expand. The authors have been in contact with NIST to ensure compatibility either by NIST making SP 800-227 more flexible, or by changing this specification to only use HKDF-Extract.

-

One of the primary design goals of this specification is for the overall composite algorithm to be able to be considered FIPS-approved even when one of the component algorithms is not. Implementers seeking FIPS certification of a Composite ML-KEM algorithm where only one of the component algorithms has been FIPS-validated or FIPS-approved should credit the FIPS-validated component algorithm with full security strength, the non-FIPS-validated component algorithm with zero security, and the overall composite should be considered full strength and thus FIPS-approved.

-

The authors wish to note that this gives composite algorithms great future utility both for future cryptographic migrations as well as bridging across jurisdictions; for example defining composite algorithms which combine FIPS cryptography with cryptography from a different national standards body.

+

One of the primary design goals of this specification is for the overall composite algorithm to be able to be considered FIPS-approved even when one of the component algorithms is not. Implementers seeking FIPS certification of a Composite ML-KEM algorithm where only one of the component algorithms has been FIPS-validated or FIPS-approved should credit the FIPS-validated component algorithm with full security strength, the non-FIPS-validated component algorithm with zero security, and the overall composite should be considered full strength and thus FIPS-approved.

+

The authors wish to note that this gives composite algorithms great future utility both for future cryptographic migrations as well as bridging across jurisdictions; for example defining composite algorithms which combine FIPS cryptography with cryptography from a different national standards body.

@@ -3979,9 +3989,9 @@

TODO: update this to NIST SP 800-227, once it is published.

One of the primary NIST documents which is relevant for certification of a composite algorithm is NIST SP.800-56Cr2 [SP.800-56Cr2] by using the allowed "hybrid" shared secret of the form Z' = Z || T. Compliance is achieved in the following way:

-

SP.800-56Cr2 section 4 "One-Step Key Derivation" requires a counter which begins at the 4-byte value 0x00000001. However, the counter is allowed to be omitted when the hash function is executed only once, as specified on page 159 of the FIPS 140-3 Implementation Guidance [FIPS-140-3-IG].

-

The HKDF-SHA2 options can be certified under SP.800-56Cr2 One-Step Key Derivation Option 1: H(x) = hash(x).

-

The SHA3 options can be certified under SP.800-56Cr2 One-Step Key Derivation Option 2: H(x) = HMAC-hash(salt, x) with the salt omitted.

+

[SP.800-56Cr2] section 4 "One-Step Key Derivation" requires a counter which begins at the 4-byte value 0x00000001. However, the counter is allowed to be omitted when the hash function is executed only once, as specified on page 159 of the FIPS 140-3 Implementation Guidance [FIPS-140-3-IG].

+

The HKDF-SHA2 options can be certified under SP.800-56Cr2 One-Step Key Derivation Option 2: H(x) = HMAC-hash(salt, x) where salt is the empty (0 octet) string, which will internally be mapped to the zero vector 0x00..00 of the correct input size for the underlying hash function in order to satisfy the requirement in [SP.800-56Cr2] that "nn the absence of an agreed-upon alternative – the default_salt shall be an all-zero byte string whose bit length equals that specified as the bit length of an input block for the hash function, hash". Note that since the desired shared secret key output length of 256 bits for all security levels aligns with the block size of SHA256, we do not need to use the HKDF-Extract step specified in [RFC5869], which further simplifies FIPS certification by allowing us to use the One-Step KDF rather than the Two-Step KDF from [SP.800-56Cr2].

+

The SHA3 options can be certified under [SP.800-56Cr2] One-Step Key Derivation Option 1: H(x) = hash(x).

diff --git a/draft-ietf-lamps-pq-composite-kem.txt b/draft-ietf-lamps-pq-composite-kem.txt index 5ff1eb5..6912042 100644 --- a/draft-ietf-lamps-pq-composite-kem.txt +++ b/draft-ietf-lamps-pq-composite-kem.txt @@ -110,8 +110,10 @@ Table of Contents 7.4. RSA-OAEP Parameters 8. Use in CMS 8.1. Underlying Components - 8.1.1. Use of the HKDF-based Key Derivation Function - 8.1.2. Use of the KMAC-based Key Derivation Function + 8.1.1. Use of the HKDF-based Key Derivation Function within + CMS + 8.1.2. Use of the KMAC-based Key Derivation Function within + CMS 8.2. RecipientInfo Conventions 8.3. Certificate Conventions 8.4. SMIMECapabilities Attribute Conventions @@ -590,11 +592,16 @@ Encap Process: 4. Encode the ciphertext - ct = mlkemCT || tradCT + ct = mlkemCT || tradCT 5. Combine the KEM secrets and additional context to yield the composite shared secret - - ss = KDF(mlkemSS || tradSS || tradCT || tradPK || Domain) + if KDF is "SHA3-256" + ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Domain) + else if KDF is "HKDF" + ss = HKDF-Extract(salt="", IKM=mlkemSS || tradSS || tradCT || tradPK || Domain) + # Note: salt is the empty string (0 octets), which will internally be mapped + # to the zero vector `0x00..00` of the correct input size for the underlying + # hash function as per [RFC 5869]. 6. Output composite shared secret key and ciphertext @@ -669,7 +676,13 @@ Decap Process: 5. Combine the KEM secrets and additional context to yield the composite shared secret - ss = KDF(mlkemSS || tradSS || tradCT || tradPK || Domain) + if KDF is "SHA3-256" + ss = SHA3-256(mlkemSS || tradSS || tradCT || tradPK || Domain) + else if KDF is "HKDF" + ss = HKDF-Extract(salt="", IKM=mlkemSS || tradSS || tradCT || tradPK || Domain) + # Note: salt is the empty string (0 octets), which will internally be mapped + # to the zero vector `0x00..00` of the correct input size for the underlying + # hash function as per [RFC 5869]. 6. Output composite shared secret key @@ -1379,7 +1392,7 @@ Deserialization Process: resistance, we use KMAC256 for the Composite ML-KEM algorithms with internally use SHA3-256, as aligned with Table 3 of [SP.800-57pt1r5]. -8.1.1. Use of the HKDF-based Key Derivation Function +8.1.1. Use of the HKDF-based Key Derivation Function within CMS The HMAC-based Extract-and-Expand Key Derivation Function (HKDF) is defined in [RFC5869]. @@ -1417,7 +1430,7 @@ Deserialization Process: The parameter field MUST be absent when this algorithm identifier is used to specify the KDF for ML-KEM in KemRecipientInfo. -8.1.2. Use of the KMAC-based Key Derivation Function +8.1.2. Use of the KMAC-based Key Derivation Function within CMS KMAC256-KDF is a KMAC-based KDF specified for use in CMS in [I-D.ietf-lamps-cms-sha3-hash]. The definition of KMAC is copied @@ -2641,16 +2654,6 @@ D.1. FIPS Certification TODO -- update this once NIST SP 800-227 is published. - EDNOTE At time of writing, it is unclear that the KEM combiner - presented in this document would pass a FIPS certification. The SHA3 - instantiations should pass under SP 800-56Cr2 Option 1, but the HKDF- - SHA2 combinations are technically not allowed under SP 800-56Cr2 even - though Option 2 allows HMAC-based constructions, but unfortunately - only HKDF-Extract is FIPS-allowed, not HKDF-Expand. The authors have - been in contact with NIST to ensure compatibility either by NIST - making SP 800-227 more flexible, or by changing this specification to - only use HKDF-Extract. - One of the primary design goals of this specification is for the overall composite algorithm to be able to be considered FIPS-approved even when one of the component algorithms is not. Implementers @@ -2676,17 +2679,29 @@ D.1.1. FIPS certification of Combiner Function the allowed "hybrid" shared secret of the form Z' = Z || T. Compliance is achieved in the following way: - SP.800-56Cr2 section 4 "One-Step Key Derivation" requires a counter + [SP.800-56Cr2] section 4 "One-Step Key Derivation" requires a counter which begins at the 4-byte value 0x00000001. However, the counter is allowed to be omitted when the hash function is executed only once, as specified on page 159 of the FIPS 140-3 Implementation Guidance [FIPS-140-3-IG]. The HKDF-SHA2 options can be certified under SP.800-56Cr2 One-Step - Key Derivation Option 1: H(x) = hash(x). - - The SHA3 options can be certified under SP.800-56Cr2 One-Step Key - Derivation Option 2: H(x) = HMAC-hash(salt, x) with the salt omitted. + Key Derivation Option 2: H(x) = HMAC-hash(salt, x) where salt is the + empty (0 octet) string, which will internally be mapped to the zero + vector 0x00..00 of the correct input size for the underlying hash + function in order to satisfy the requirement in [SP.800-56Cr2] that + "nn the absence of an agreed-upon alternative – the default_salt + shall be an all-zero byte string whose bit length equals that + specified as the bit length of an input block for the hash function, + hash". Note that since the desired shared secret key output length + of 256 bits for all security levels aligns with the block size of + SHA256, we do not need to use the HKDF-Extract step specified in + [RFC5869], which further simplifies FIPS certification by allowing us + to use the One-Step KDF rather than the Two-Step KDF from + [SP.800-56Cr2]. + + The SHA3 options can be certified under [SP.800-56Cr2] One-Step Key + Derivation Option 1: H(x) = hash(x). D.2. Backwards Compatibility diff --git a/index.html b/index.html index 993b902..cbe2a10 100644 --- a/index.html +++ b/index.html @@ -37,7 +37,7 @@

Preview for branch mikeo_97

Composite ML-KEM plain text - same as main + diff with main

Preview for branch mikeo_hkdf