Add MLKEM1024-P384 hybrid KEM support in HPKE#14722
Merged
Merged
Conversation
Implements the MLKEM1024-P384 hybrid KEM (KEM ID 0x0051) as specified in
draft-ietf-hpke-pq. This combines ML-KEM-1024 with ECDH over NIST P-384,
using the QSF-style SHA3-256 combiner:
ss = SHA3-256(ss_PQ || ss_T || ct_T || ek_T || "MLKEM1024-P384")
Exposes MLKEM1024P384PrivateKey / MLKEM1024P384PublicKey, which accept
an MLKEM1024Private/PublicKey plus a SECP384R1 EllipticCurvePrivate/
PublicKey, and wires them through the new KEM.MLKEM1024_P384 variant.
Validated end-to-end against the draft-ietf-hpke-pq test vectors via
test_vector_decryption.
https://claude.ai/code/session_01WMt6uNpXMN2skhuiEtEMx7
alex
commented
Apr 23, 2026
- Consolidate mlkem768_x25519_combine and mlkem1024_p384_combine into a single hybrid_kem_combine helper that takes the label as an argument. Both KEMs use the same QSF-style SHA3-256 combiner structure (ss_PQ || ss_T || ct_T || ek_T || Label), so the duplication wasn't pulling its weight. - Move MLKEM1024P384Private/PublicKey assignments under the MLKEM768X25519 ones in cryptography/hazmat/primitives/hpke.py to match the ordering of __all__. https://claude.ai/code/session_01WMt6uNpXMN2skhuiEtEMx7
reaperhulk
approved these changes
Apr 24, 2026
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
Summary
Adds the MLKEM1024-P384 hybrid KEM (KEM ID
0x0051) fromdraft-ietf-hpke-pq
to HPKE, combining ML-KEM-1024 with ECDH over NIST P-384 using the
QSF-style SHA3-256 combiner:
Exposes
MLKEM1024P384PrivateKey/MLKEM1024P384PublicKeywhich takean
MLKEM1024Private/PublicKeyplus a SECP384R1EllipticCurvePrivate/PublicKey, wired through the newKEM.MLKEM1024_P384variant. Mirrors the existingMLKEM768X25519PrivateKey/MLKEM768X25519PublicKeypattern fromAdd MLKEM768-X25519 hybrid KEM support in HPKE #14695.
Validated end-to-end against the draft-ietf-hpke-pq vectors in
vectors/cryptography_vectors/HPKE/hpke-pq-test-vectors.jsonvia theexisting
test_vector_decryptiontest (now covering KEM ID0x0051),plus new format/type-error/round-trip tests.
Like
MLKEM768_X25519, this KEM is only available on backends with bothML-KEM and SHA3-256 (so: AWS-LC; skipped on BoringSSL because it lacks
SHA3).
Test plan
OPENSSL_DIR=/path/to/aws-lc nox -e localpasses (ruff, clippy,mypy, pytest, cargo tests)
test_hpke.pypasses, includingtest_vector_decryptionagainstthe IETF draft vectors
test_ciphertext_format_mlkem1024_p384,test_wrong_key_mlkem1024_p384,test_mlkem1024_p384_wrong_kem_with_ec,test_mlkem1024_p384_constructor_type_errorshttps://claude.ai/code/session_01WMt6uNpXMN2skhuiEtEMx7
Generated by Claude Code