-
Notifications
You must be signed in to change notification settings - Fork 13
Update ML-KEM for compatibility with OpenSSL 3.5 implementation #153
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
Open
mamckee
wants to merge
11
commits into
main
Choose a base branch
from
mamckee-mlkem-3_5-updates
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Changes from all commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
2c659f1
Stub out ML-KEM interfaces
mamckee a1c7622
Split mlkem standalone key management
mamckee d9db9f5
Standalone MLKEM
mamckee 433cec2
Hybrid key management
mamckee d744cf2
Re-add hybrid ML-KEM
mamckee 2e9ee09
Separate ML-KEM decoders
mamckee 5df799c
Separate MLKEM encoders
mamckee 3ad9f75
Cleanup
mamckee b75d07f
Add comment indicating hybrids are only for TLS
mamckee cd59a30
Cleanup and add explicit ikme rejection
mamckee 66b665e
Add mlkem evp_test
mamckee File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
Large diffs are not rendered by default.
Oops, something went wrong.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
This section is curious to me - looking at latest OpenSSL and 3.5, the SN and OIDs for hybrid key exchange do not seem to be defined, also the LN is different.
It seems particularly funky to define these OIDs for hybrids with the NIST algorithm identifiers: https://csrc.nist.gov/projects/computer-security-objects-register/algorithm-registration
NIST owns the 2.16.840.1.101.3 OID space and does not define these hybrids.
i.e.
PROV_NAMES_X25519MLKEM768 is "X25519MLKEM768", not "X25519-ML-KEM-768"
PROV_NAMES_SecP256r1MLKEM768 is "SecP256r1MLKEM768", not "P256-ML-KEM-768"
PROV_NAMES_SecP384r1MLKEM1024 is "SecP384r1MLKEM1024"
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.
As far as the OIDs go, since we don't need to encode or decode, we can just remove them. I believe these were the same OIDs that the oqs provider were using as a placeholder, but it looks like no OIDs are on the table for these hybrids anyways.
The SNs are in line with other openssl SNs, and the hybrids are registered with the name that provider name used in the default provider. OpenSSL doesn't define any SNs or NIDs for these algorithms, but having a NID for these is convenient.
The provider name and SN don't always match, but usually both are used as the algorithm name in the dispatch table. I know the order can matter (e.g. for digests, the first name is used for
EVP_MD_name, so SHA256 returns "SHA2-256" instead of the SN) but I'm not sure about KEM. I can make the provider name come first in the list to be safe.