-
Notifications
You must be signed in to change notification settings - Fork 3
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
base: main
Are you sure you want to change the base?
Conversation
draft-ietf-lamps-pq-composite-kem.md
Outdated
|
||
## 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. |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
EDNOTE / TODO: we should discuss on the LAMPS list whether to add this back in. |
Remove this ednote.
I should do another pass at making the text clearer. "This specification" is unclear -- I should say "Composite KEM". |
Closes #91
TODO before merging: