MLKEM-768 with AWS-LC by DarkaMaul · Pull Request #14598 · pyca/cryptography

DarkaMaul · 2026-04-07T16:06:03Z

Add the support for ML-KEM using AWS-LC as the backend.

The PR is massive (sorry), about 1000 lines, but I could not reduce it more.

It follows closely the pattern of MLDSA, with the latest changes (class cases, variant enum)

A following PR with the documentation will be opened once this one get merged.

(Note: until aws/aws-lc#3140 is fixed, we have to store the ML-KEM seed on our side)

# Conflicts: # src/cryptography/hazmat/primitives/asymmetric/types.py # src/rust/cryptography-key-parsing/src/pkcs8.rs # src/rust/cryptography-key-parsing/src/spki.rs

alex · 2026-04-08T02:24:59Z

src/cryptography/hazmat/primitives/asymmetric/mlkem.py

+        return rust_openssl.mlkem.from_mlkem768_public_bytes(data)
+
+    @abc.abstractmethod
+    def encapsulate(self) -> tuple[bytes, bytes]:


@reaperhulk WDYT?

This matches the go API

alex · 2026-04-08T02:29:38Z

src/rust/cryptography-key-parsing/src/pkcs8.rs

+        // ML-KEM returns the seed rather than a PKey because AWS-LC's
+        // kem_priv_encode writes the expanded key (2,400 bytes) into PKCS#8,
+        // not the seed.


I don't understand this comment.

I've updated it to clarify it.
I wanted to say that we can't use OpenSSL PKey construct here, so we need a second element in our ParsedPrivateKey enum.

alex · 2026-04-08T02:29:57Z

src/rust/cryptography-key-parsing/src/pkcs8.rs

 }

 pub fn serialize_private_key(key: &ParsedPrivateKey) -> crate::KeySerializationResult<Vec<u8>> {
-    let ParsedPrivateKey::Pkey(pkey) = key;


Can you refactor this out into its own PR for readability

Open as #14607

alex · 2026-04-08T02:30:31Z

src/rust/cryptography-openssl/src/mlkem.rs

+}
+
+extern "C" {
+    fn EVP_PKEY_kem_new_raw_public_key(


I don't think you need to declare these, they should just be available in ffi::

Correct, only EVP_PKEY_keygen_deterministic is needed because it is still in experimental/ in aws-lc.

IIUC, this is Algorithm 16 in FIPS 203.

Using this function allows us to use the seed form of the private key.

alex · 2026-04-08T02:32:58Z

src/rust/src/backend/mlkem.rs

+        format: crate::serialization::PrivateFormat,
+        encryption_algorithm: &pyo3::Bound<'p, pyo3::PyAny>,
+    ) -> CryptographyResult<pyo3::Bound<'p, pyo3::types::PyBytes>> {
+        if !encryption_algorithm.is_instance(&types::KEY_SERIALIZATION_ENCRYPTION.get(py)?)? {


Why did we end up needing to re-implement a ton of the utility function whereas that wasn't required for MLDSA?

The problem here is that we can't represent the private key as an openssl PKey (AWS-LC's kem_priv_encode writes the expanded key into PKCS#8, not the seed), so we can't use pkey_private_bytes here.

We have another solution by refactoring pkey_private_bytes to:

accept the new enum ParsedPrivateKey as argument

// Replace this line with a match {} let raw_bytes = pkey.raw_private_key()?; return Ok(pyo3::types::PyBytes::new(py, &raw_bytes));

Revert

let parsed = cryptography_key_parsing::ParsedPrivateKey::Pkey(pkey.to_owned());

Gate before if format == PrivateFormat::TraditionalOpenSSL { to ensure we're not reaching this for MLKem keys

The main downside is that the refactor modifies every caller of the function from &slf.borrow().pkey, to ParsedPrivateKey::Pkey(slf.borrow().pkey.to_owned())

That would avoid the deduplication here (and the need for extensive tests for each variant of the encryption part)

If the aws-lc change to store the seed on the pkey lands, we'll need neither of these changes, right?

Correct! Once we can represent MLKEM's key as PKey, all this complexity goes away

Let's add a comment clearly indicating this (with a link to the issue/PR)

Landed as aws/aws-lc#3149

In this case, I think it's better to wait for a new version of AWS-LC, so we remove this complexity?

If we think that'll be in a release soon (<10 days), then waiting seems ok. If not, landing and then following up with the cleanup seems preferable.

v1.72.0 has been released !
I'll updated my PR!

tests/hazmat/primitives/test_mlkem.py

# Conflicts: # src/rust/cryptography-key-parsing/src/pkcs8.rs

src/rust/cryptography-key-parsing/src/lib.rs

src/rust/src/backend/mlkem.rs

# Conflicts: # src/cryptography/hazmat/primitives/asymmetric/types.py

alex · 2026-04-11T15:18:21Z

src/rust/cryptography-openssl/src/mlkem.rs

+}
+
+extern "C" {
+    fn EVP_PKEY_keygen_deterministic(


can you add a comment that this is needed because its in the expiremental header

(The review comment got displaced by GitHub UI, but a comment was added Line 42 )

alex · 2026-04-11T15:20:21Z

src/rust/src/backend/keys.rs

+        #[cfg(CRYPTOGRAPHY_IS_AWSLC)]
+        cryptography_key_parsing::ParsedPrivateKey::MlKem(variant, seed) => {
+            let pkey = cryptography_openssl::mlkem::new_from_seed(variant, &seed)?;
+            Ok(


should probably match on variant here?

alex · 2026-04-11T15:20:50Z

src/rust/src/backend/keys.rs

+            let pub_len = pkey.raw_public_key()?.len();
+            assert_eq!(


Can we do the match pattern here (like mldsa) so it's ready for other variants

alex · 2026-04-11T15:21:45Z

src/rust/src/backend/mlkem.rs

+        format: crate::serialization::PrivateFormat,
+        encryption_algorithm: &pyo3::Bound<'p, pyo3::PyAny>,
+    ) -> CryptographyResult<pyo3::Bound<'p, pyo3::types::PyBytes>> {
+        if !encryption_algorithm.is_instance(&types::KEY_SERIALIZATION_ENCRYPTION.get(py)?)? {


Let's add a comment clearly indicating this (with a link to the issue/PR)

alex · 2026-04-11T15:22:56Z

tests/hazmat/primitives/test_mlkem.py

+            ss_n = key.decapsulate(binascii.unhexlify(vector["ct_n"]))
+            assert ss_n == binascii.unhexlify(vector["ss_n"])
+
+    @pytest.mark.parametrize(


I would like a test or two that load a specific key and asserts about the parsed results.

I've added a test for the serialization, but I don't think we can test reliably the encryption part.

(Added as part of this PR, but it contains two new test vectors. If you agree with the approach, I'll move them in a separate PR)

alex · 2026-04-11T15:23:48Z

tests/wycheproof/test_mlkem.py

+    skip_message="Requires a backend with ML-KEM-768 support",
+)
+@wycheproof_tests("mlkem_768_encaps_test.json")
+def test_mlkem768_encaps(backend, wycheproof):


Do we have private key to decap and verify it round trips?

I believe this is covered by the test_kat_vectors in tests/hazmat/primitives/test_mlkem.py.
We decapsulate there the ciphertext ct, and verify that the shared secret is correct .

But I think I'm not understanding your comment here.

alex · 2026-04-11T15:24:14Z

src/rust/cryptography-openssl/src/mlkem.rs

+}
+
+pub fn encapsulate(
+    variant: MlKemVariant,


Do we need to pass variant, or can we extract it from pkey? (I want to avoid them not being consistent with each other)

Updated to not use the variant here.

DarkaMaul added 16 commits March 23, 2026 12:10

Add EVP Encapsulation

9d3a36a

Initial implementation

d879097

Add EVP Encapsulation

bc2b978

Clean pattern

21b6c24

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

cd376b7

Merge remote-tracking branch 'fork/parse-key-refactor' into dm/mlkem-768

ff5c44e

Fix tests

9268f51

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

2cf6f56

Rebase PR

c40292a

Update work

59be3dd

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

4080b75

More review

f5fc54f

Update

07ad820

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

ef3762d

# Conflicts: # src/cryptography/hazmat/primitives/asymmetric/types.py # src/rust/cryptography-key-parsing/src/pkcs8.rs # src/rust/cryptography-key-parsing/src/spki.rs

Fix tests

52936e2

Fix formattign

bf17e51

alex reviewed Apr 8, 2026

View reviewed changes

This was referenced Apr 8, 2026

Add KAT for ML-KEM #14606

Merged

Formatting PKCS#8 match arm #14607

Merged

DarkaMaul added 3 commits April 8, 2026 04:09

Remove useless declarations

4323131

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

97f2810

# Conflicts: # src/rust/cryptography-key-parsing/src/pkcs8.rs

More review

d054405

DarkaMaul commented Apr 8, 2026

View reviewed changes

src/rust/cryptography-key-parsing/src/lib.rs Outdated Show resolved Hide resolved

DarkaMaul added 2 commits April 9, 2026 09:21

Merge branch 'main' into dm/mlkem-768

e112582

Fix tests

61c75e8

alex reviewed Apr 9, 2026

View reviewed changes

src/rust/src/backend/mlkem.rs Outdated Show resolved Hide resolved

DarkaMaul added 2 commits April 10, 2026 04:42

Fix missing coverage

6488888

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

449dbf7

# Conflicts: # src/cryptography/hazmat/primitives/asymmetric/types.py

alex reviewed Apr 11, 2026

View reviewed changes

Merge branch 'main' into dm/mlkem-768

ebc6dc0

DarkaMaul added 5 commits April 13, 2026 04:27

Move to variants

ca93938

Remove variant from encapsule/decapsulate

51a2a84

Add experimental comment

43b473f

Add tests for the serialization part

62eac99

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

d87d813

DarkaMaul mentioned this pull request Apr 14, 2026

Fix EC point-at-infinity key loading raising InternalError on AWS-LC #14652

Merged

DarkaMaul added 3 commits April 14, 2026 06:28

Update to AWS 1.72

791adae

Merge remote-tracking branch 'origin/main' into dm/mlkem-768

a627657

Fix coverage

1545b88

Conversation

DarkaMaul commented Apr 7, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Milestone

Development

Uh oh!

2 participants