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.

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 2 commits into
base: main
Choose a base branch
from

Conversation

ounsworth
Copy link
Contributor

@ounsworth ounsworth commented Jan 6, 2025

Closes #91

TODO before merging:

  • Review from Peter C, especially:
    • the new appendix comparing this specification with ETSI CatKDF
    • The intro is still a bit misleading about the endorsement from BSI, which Peter C correctly points out is to an earlier version of the composite draft, however we have Jan Klaußner as an author and close collaboration with Stavros Kousidis on the CFRG version, so BSI is a bull collaborator on developing this.
  • Review from Chris Wood / Deirdre / Bas, especially:
    • The new appendix comparing this specification with X-Wing
  • I was not previously aware of ETSI TS 103 744's CatKDF. We should have a discussion on the LAMPS list about whether we want to add the ML-KEM CT to the KDF in order to offer equivalent security properties as ETSI CatKDF.


## X-Wing

Thit 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 explicitely disallowed by [FIPS.203] which makes it impossible to create a FIPS-compliant implentation of X-Wing. 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.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • Typo: Thit
  • "is explicitely disallowed". Presently.
  • "it impossible to create a FIPS-compliant" of X-Wing private key import.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, fixed.

Yeah, if NIST eventually softens the prohibition on derived seeds, that would be fantastic and then X-Wing and Composite could fully collapse together, but NIST has not given any indication of when / how / if they are going to do that, so for now I think we need to proceed like this. Sigh.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Given the stated plan, and the fact that there are no ML-KEM-768 modules yet, wouldn't it make sense for the long term to align id-MLKEM768-X25519 with X-Wing. Of course you would want to do something different for the P256 one.


This specification does not bind the ML-KEM ciphertext -- which is MA in the ETSI CatKDF.

EDNOTE / TODO: we should discuss on the LAMPS list whether to add this back in.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
EDNOTE / TODO: we should discuss on the LAMPS list whether to add this back in.

Remove this ednote.

@ounsworth
Copy link
Contributor Author

I should do another pass at making the text clearer. "This specification" is unclear -- I should say "Composite KEM".
Should also describe more clearly that that paragraph is just highlighting that these are different constructions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Composite KEM does not fully protect against implementation errors in ML-KEM
2 participants