Skip to content
New issue

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

Sign up for GitHub

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

Already on GitHub? Sign in to your account

Added appdx comparing with X-Wing and ETSI CatKDF. #101

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+34 −2
Open

Added appdx comparing with X-Wing and ETSI CatKDF. #101

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d2714f5
Added appdx comparing with X-Wing and ETSI CatKDF. Closes #91
ounsworth Jan 6, 2025
6e97f2d
comments from Bas
ounsworth Jan 7, 2025
87a652a
Adjusted wording thanks to Peter C
ounsworth Jan 26, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 34 additions & 2 deletions draft-ietf-lamps-pq-composite-kem.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -234,6 +234,12 @@ informative:
author:
org: National Institute of Standards and Technology (NIST)
date: July 26, 2024
ETSI.TS.103.744:
title: "ETSI TS 103 744 V1.1.1 CYBER; Quantum-safe Hybrid Key Exchanges"
target: https://www.etsi.org/deliver/etsi_ts/103700_103799/103744/01.01.01_60/ts_103744v010101p.pdf
author:
org: ETSI
date: 2020-12


--- abstract
Expand Down Expand Up @@ -261,7 +267,7 @@ Editorial changes:
* ASN.1 module fixes (thanks Russ and Carl).
* Renamed the module from Composite-KEM-2023 -> Composite-MLKEM-2024
* Simplified the ASN.1 module to make it more compiler-friendly (thanks Carl!) -- should not affect wire encodings.

* Added an appendix "Comparison with other Hybred KEMs" with sub-sections on X-Wing and ETSI CatKDF

Still to do in a future version:

Expand All @@ -281,7 +287,7 @@ Cautious implementers may opt to combine cryptographic algorithms in such a way

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].

In addition, [BSI2021] specifically references this specification as a concrete example of hybrid X.509 certificates.
In addition, [BSI2021] specifically references the composite specification as a concrete example of hybrid X.509 certificates.

A more recent example is [ANSSI2024], a document co-authored by French Cybersecurity Agency (ANSSI),
Federal Office for Information Security (BSI), Netherlands National Communications Security Agency (NLNCSA), and
Expand Down Expand Up @@ -1585,6 +1591,32 @@ With regard to the traditional algorithms, RSA or Elliptic Curve, in order to ac

<!-- End of Implementation Considerations section -->

# Comparison with other Hybred KEMs

## X-Wing

This specification borrows extensively from the analysis and KEM combiner construction presented in [X-Wing]. In particular, X-Wing and id-MLKEM768-X25519 are largely interchangeable. The one difference is that X-Wing uses a combined KeyGen function to generate the two component private keys from the same seed, which gives some additional binding properies. However, using a derived value as the seed for ML-KEM.KeyGen_internal() is, at time of writing, explicitely disallowed by [FIPS.203] which makes it impossible to create a FIPS-compliant implentation of X-Wing KeyGen / private key import. For this reason, this specification keeps the key generatation for both components separate so that implementers are free to use an existing certified hardware or software module for one or both components.

Due to the difference in key generation and security properties, X-Wing and id-MLKEM768-X25519 have been registered as separate algorithms with separate OIDs, and they use a different domain separator string in order to ensure that their ciphertexts are not inter-compatible.

## ETSI CatKDF

[ETSI.TS.103.744] section 8.2 defines CatKDF as:

~~~
1) Form secret = psk || k1 || k 2 || … || k n.
2) Set f_context = f(context, MA, MB), where f is a context formatting function.
3) key_material = KDF(secret, label, f_context, length).
4) Return key_material.

MA shall contain all of the public keys.
MB shall contain all of the corresponding public keys and ciphertexts.
~~~

The main difference between the Composite KEM combiner and the ETSI CatKDF combiner is that CatKDF makes the more conservative choice to bind the public keys and ciphertexts of both components, while Composite KEM follows the analysis presented in [X-Wing] that while preserving the security properties of the traditional component requires binding the public key and ciphertext of the traditional component, it is not necessary to do so for ML-KEM thanks to the rejection sampling step of the Fujisaki-Okamoto transform.

Additionally, ETSI CatKDF uses HKDF [RFC5869] as the KDF which aligns with some of the variants in this specification, but not the ones that use SHA3.


# Intellectual Property Considerations

Expand Down
Loading