MLDSA65 support for AWS-LC by DarkaMaul · Pull Request #14404 · pyca/cryptography

DarkaMaul · 2026-03-02T17:11:47Z

This PR adds ML-DSA-65 support when using the AWS-LC backend.

I know this PR is quite massive (+1000 lines), but I've already excluded the documentation from it. I can split it even further by:

only add the Python tests and gate them behind the mldsa_supported() -> bool = False so the test suite continue to pass (would be about 500 lines)
only add the Rust code to exercise the tests

I could also try to remove the x509/pkcs8 support, but in my tests, that led to a weird API state where some functions would not work.

I'm also happy to also split it in any other potential better ways if you see any.

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

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

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

DarkaMaul · 2026-03-02T17:22:36Z

src/rust/src/backend/mldsa.rs

+        // Note: private_key_to_pkcs8() (i2d_PKCS8PrivateKey_bio) must be used
+        // instead of private_key_to_der() (i2d_PrivateKey), because AWS-LC's
+        // i2d_PrivateKey doesn't support PQDSA keys.
+        let pkcs8_der = self.pkey.private_key_to_pkcs8()?;


FLAG: This is not elegant here - but moving this to another layer (like the cryptography-openssl crate would induce a new dependency on asn1)

alex · 2026-03-02T22:49:00Z

Can you take a look at the missing coverage before I review? (If there's questions about idioms for covering certain things, let me know)

src/rust/src/backend/mldsa.rs

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

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

src/rust/src/backend/mldsa65.rs

src/rust/src/backend/mldsa.rs

tests/hazmat/primitives/test_mldsa65.py

abbra · 2026-03-05T21:26:29Z

@DarkaMaul any reason you were not basing on my branches?

alex · 2026-03-05T21:34:20Z

@abbra -- please do not nag contributors about this. As I last checked, your branch is far too large to be reviewable, is targeting OpenSSL rather than the backends we intend to start with, and you have not submitted any of it for review as a PR. In contrast, this pull request is moving towards a mergable state, so attempting to rebase it on top of your work would be a hinderance, rather than a help.

abbra · 2026-03-05T21:43:29Z

@alex I have splitted the code into three different branches: for ML-DSA-44, ML-DSA-65, ML-DSA-87, as you and Paul did request. I haven't submitted any of them individually because you asked not to submit them without non-OpenSSL backend.

I'd like to at least have higher level API agreed. Do you want me to submit those branches now?

reaperhulk · 2026-03-05T21:50:39Z

@abbra It’s great that you split them, but you didn’t submit anything to us for review. Our development happens in the open on this issue tracker and at this time other contributors have stepped forward and have submitted things we’re actively reviewing. Their work is going to take priority, but hopefully you’ll be able to rebase on top of them to submit going forward.

abbra · 2026-03-05T21:56:57Z

@reaperhulk looks like we misunderstood each other then.
I have opened #14430 for your consideration. Please help to improve higher level API PyCA eventually would like to see for ML-DSA operations.

alex

if we're adding new vectors they need to be documented in test-vectors.rst

src/cryptography/hazmat/bindings/_rust/openssl/__init__.pyi

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

alex · 2026-03-06T01:53:28Z

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

+    def private_bytes_raw(self) -> bytes:
+        """
+        The raw bytes of the private key (32-byte seed).
+        Equivalent to private_bytes(Raw, Raw, NoEncryption()).


Same Q here about seed.

(replied about this one in public_bytes_raw comment)

I wonder if we should be using the noun seed here, rather than raw -- wdyt @reaperhulk ?

@reaperhulk still pending :-)

Hmm, well a seed only key can have two forms. The raw/bare seed or one wrapped in a PKCS8 structure. This parses the raw seed so I think I'm fine with it being called raw?

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

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

alex · 2026-03-06T01:54:48Z

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

+    fn test_serialize_public_key_unsupported_mldsa_variant() {
+        // Load an ML-DSA-44 public key from a Wycheproof test vector DER.
+        let der = include_bytes!(
+            "../../../../vectors/cryptography_vectors/asymmetric/MLDSA/mldsa44_pub.der"


Tests like this should go through the Python interface -- we generally only do rust tests if the code is actually unreachable from python

That's actually unreachable from Python at the moment because we can't construct an ML-DSA-44 key object in the Python layer. The serialize_public_key path is only called from public_bytes() on an MlDsa65PublicKey, and all constructors that produce that type validate the key size upfront.

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

src/rust/src/backend/mldsa65.rs

tests/wycheproof/test_mldsa.py

docs/development/custom-vectors/mldsa/generate_mldsa.py

alex · 2026-03-12T23:37:58Z

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

+    def private_bytes_raw(self) -> bytes:
+        """
+        The raw bytes of the private key (32-byte seed).
+        Equivalent to private_bytes(Raw, Raw, NoEncryption()).


I wonder if we should be using the noun seed here, rather than raw -- wdyt @reaperhulk ?

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

alex · 2026-03-12T23:41:09Z

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

        }

+        #[cfg(CRYPTOGRAPHY_IS_AWSLC)]
+        AlgorithmParameters::MlDsa65 => parse_mldsa_private_key(k.private_key),


I think we need a length check here? Or is something lower in the stack verifying that the length matches the mldsa type?

What about open-coding the parsing? Check if the length is correct and that the prefix is the expected value. Then return the suffix.

There is a length check deeper in the chain:

// Get PQDSA instance and validate lengths const PQDSA *pqdsa = PQDSA_KEY_get0_dsa(ret->pkey.pqdsa_key); if (len != pqdsa->private_key_len && len != pqdsa->keygen_seed_len) { OPENSSL_PUT_ERROR(EVP, EVP_R_INVALID_BUFFER_SIZE); goto err; }

source

I have written the following test to confirm it.

#[cfg(CRYPTOGRAPHY_IS_AWSLC)] #[test] fn test_parse_mldsa_private_key_wrong_size() { let bad_seed = asn1::write_single(&super::MlDsaPrivateKey::Seed(&[0u8; 33])).unwrap(); assert!(super::parse_mldsa_private_key(&bad_seed).is_err()); }

alex · 2026-03-12T23:44:38Z

src/rust/src/backend/keys.rs

            .into_any()),

+        #[cfg(CRYPTOGRAPHY_IS_AWSLC)]
+        id if id == openssl::pkey::Id::from_raw(cryptography_openssl::mldsa::NID_PQDSA) => {


This is released now.

src/rust/src/backend/keys.rs

src/rust/src/backend/mldsa.rs

tests/hazmat/primitives/test_mldsa.py

alex · 2026-03-12T23:49:45Z

tests/wycheproof/test_mldsa.py

+)
+@wycheproof_tests("mldsa_65_sign_seed_test.json")
+def test_mldsa65_sign_seed(backend, wycheproof):
+    # Skip "Internal" tests


Err, what's an internal test?

A test that uses Sign_internal (Algorithm 7) instead of Sign (Algorithm 2)

IIUC, the Sign_internal method is the inner signing method, that is called by Sign using an already computed mix of (msg, ctx, public_key).

FIPS 204

(Definition is here)

can you expand this comment very slightly.

alex · 2026-03-12T23:50:34Z

This is making good progress, I think we're close.

# Conflicts: # vectors/cryptography_vectors/asymmetric/MLDSA/mldsa65_noseed_priv.der

alex

pretty close!

alex · 2026-03-24T22:27:44Z

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

+        self,
+        encoding: _serialization.Encoding,
+        format: _serialization.PrivateFormat,
+        encryption_algorithm: (_serialization.KeySerializationEncryption),


Suggested change

encryption_algorithm: (_serialization.KeySerializationEncryption),

encryption_algorithm: _serialization.KeySerializationEncryption,

alex · 2026-03-24T22:27:57Z

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

+    def private_bytes_raw(self) -> bytes:
+        """
+        The raw bytes of the private key (32-byte seed).
+        Equivalent to private_bytes(Raw, Raw, NoEncryption()).


@reaperhulk still pending :-)

alex · 2026-03-24T22:28:40Z

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

+#[cfg(CRYPTOGRAPHY_IS_AWSLC)]
+// NO-COVERAGE-START
+#[derive(asn1::Asn1Read, asn1::Asn1Write)]
+// NO-COVERAGE-END


We've never needed these markers on an asn1derive, strongly suggests there's some relevant path that we're never using -- do we not use both read/write on this type?

We do both use the read and write operation here, but the macro generates more code there.

I used cargo expand on the macro to generate a new coverage run on the expanded version:

The CI fails with the following missing lines:

src/rust/cryptography-key-parsing/src/pkcs8.rs 383 14 0 0 96% 39-40, 48-53, 79-84

L39-40: this could be exercised by having a test that calls asn1::write_single(&MlDsaPrivateKey::Seed(wrong_seed)) but in practice, that would mean the raw_private_key returned an invalid seed, and that should not be doable.

.map_err(|e| { e.add_location(asn1::ParseLocation::Field("MlDsaPrivateKey::Seed")) })?

L48-53: not sure how to test this

fn can_parse(tag: asn1::Tag) -> bool { if asn1::Implicit::<&'a [u8], 0>::can_parse(tag) { return true; } false }

L79-84: same here, we are using the impl for MlDsaPrivateKey not &MlDsaPrivateKey

impl<'a> asn1::Asn1Writable for &MlDsaPrivateKey<'a> { type Error = asn1::WriteError; fn write(&self, w: &mut asn1::Writer<'_>) -> asn1::WriteResult { (*self).write(w) } fn encoded_length(&self) -> Option<usize> { (*self).encoded_length() } }

(source)

What's the best/recommended practice here?

Huh... I am not sure. I'm baffled how we've never run into these with any other enums before...

Not required anymore thanks to our new runner!

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

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

src/rust/src/backend/mldsa.rs

tests/wycheproof/test_mldsa.py

alex · 2026-03-24T22:35:30Z

tests/wycheproof/test_mldsa.py

+)
+@wycheproof_tests("mldsa_65_sign_seed_test.json")
+def test_mldsa65_sign_seed(backend, wycheproof):
+    # Skip "Internal" tests


can you expand this comment very slightly.

alex

Final mile!

alex · 2026-03-27T01:16:36Z

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

+#[cfg(CRYPTOGRAPHY_IS_AWSLC)]
+// NO-COVERAGE-START
+#[derive(asn1::Asn1Read, asn1::Asn1Write)]
+// NO-COVERAGE-END


Huh... I am not sure. I'm baffled how we've never run into these with any other enums before...

alex · 2026-03-27T01:18:10Z

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

+// NO-COVERAGE-END
+pub enum MlDsaPrivateKey<'a> {
+    #[implicit(0)]
+    Seed(&'a [u8]),


Should this be a [u8; 32]? the RFC defines it as SIZE 32.

Yes! And narrowing it surfaced a bug because this was happily serializing the expanded private key instead of the seed.

I've also modified the test_round_trip_private_serialization to add the missing equality...

alex · 2026-03-27T01:19:37Z

src/rust/src/backend/mldsa.rs

+        &self,
+        py: pyo3::Python<'p>,
+    ) -> CryptographyResult<pyo3::Bound<'p, pyo3::types::PyBytes>> {
+        // AWS-LC's raw_private_key() returns the expanded key, not the seed.


Is this still true? IIUC this was changed.

alex · 2026-03-27T01:19:48Z

src/rust/src/backend/mldsa.rs

+        encryption_algorithm: &pyo3::Bound<'p, pyo3::PyAny>,
+    ) -> CryptographyResult<pyo3::Bound<'p, pyo3::types::PyBytes>> {
+        // Intercept Raw/Raw/NoEncryption so we return the seed.
+        // The generic pkey_private_bytes raw path calls raw_private_key()


MLDSA65 support for AWS-LC

176e34b

DarkaMaul commented Mar 2, 2026

View reviewed changes

src/cryptography/hazmat/primitives/asymmetric/mldsa.py Show resolved Hide resolved

DarkaMaul commented Mar 2, 2026

View reviewed changes

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

DarkaMaul commented Mar 2, 2026

View reviewed changes

src/rust/cryptography-openssl/src/mldsa.rs Show resolved Hide resolved

DarkaMaul commented Mar 2, 2026

View reviewed changes

DarkaMaul force-pushed the dm/mldsa65-aws-lc branch from 49220b3 to 4f4bc0b Compare March 3, 2026 13:25

Improve coverage

65ab941

DarkaMaul force-pushed the dm/mldsa65-aws-lc branch from 4f4bc0b to 65ab941 Compare March 3, 2026 13:38

DarkaMaul commented Mar 3, 2026

View reviewed changes

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

Initial review

4fab32f

alex reviewed Mar 4, 2026

View reviewed changes

DarkaMaul added 2 commits March 5, 2026 05:44

First round of review

2450b41

Clean tests

ef4345f

alex reviewed Mar 6, 2026

View reviewed changes

DarkaMaul added 4 commits March 6, 2026 03:29

Revert spurious formatting

2f6b313

Incorporate review

4fe06c7

Rename from mldsa65 to mldsa

ed6d9de

Improve serialization/deserialization

b60d88b

alex mentioned this pull request Mar 7, 2026

ML-DSA-44 support (OpenSSL backend) #14430

Open

DarkaMaul added 2 commits March 9, 2026 06:35

Fix coverage

39c9db3

Use ASN1 struct to parse the private key

db6d98d

alex reviewed Mar 12, 2026

View reviewed changes

docs/development/custom-vectors/mldsa/generate_mldsa.py Outdated Show resolved Hide resolved

alex reviewed Mar 12, 2026

View reviewed changes

DarkaMaul mentioned this pull request Mar 13, 2026

Add other MLDSA test vectors #14470

Merged

DarkaMaul and others added 12 commits March 13, 2026 11:04

Merge branch 'pyca:main' into dm/mldsa65-aws-lc

c78a527

Use Enum instead of Struct

7bde7d5

Inline function

a8083a4

Change match arm

f849147

Remove duplicate comment

7284fec

Change unimplemented by assert

16bd0d3

More review fix

b66fdca

Merge branch 'pyca:main' into dm/mldsa65-aws-lc

67c5374

Fix Wycheproof vectors handling

e457a27

Add NO-COVERAGE marker

8cb4c7e

Merge remote-tracking branch 'origin/main' into dm/mldsa65-aws-lc

a532164

# Conflicts: # vectors/cryptography_vectors/asymmetric/MLDSA/mldsa65_noseed_priv.der

Remove vectors

c56210c

DarkaMaul force-pushed the dm/mldsa65-aws-lc branch from 0bf9bf9 to c56210c Compare March 24, 2026 08:47

alex reviewed Mar 24, 2026

View reviewed changes

DarkaMaul added 3 commits March 25, 2026 04:20

Merge remote-tracking branch 'origin/main' into dm/mldsa65-aws-lc

b2cd7dd

Review comments

f492ca3

Remove markers

d517b35

DarkaMaul mentioned this pull request Mar 25, 2026

Add a new CI job with Rust 1.83 and AWS-LC #14541

Merged

DarkaMaul added 2 commits March 26, 2026 09:30

Merge branch 'pyca:main' into dm/mldsa65-aws-lc

530aa92

Merge branch 'pyca:main' into dm/mldsa65-aws-lc

4b8430c

alex reviewed Mar 27, 2026

View reviewed changes

Additional round of review

1f1303a

DarkaMaul force-pushed the dm/mldsa65-aws-lc branch from 7a1087e to 1f1303a Compare March 27, 2026 10:54

Merge branch 'pyca:main' into dm/mldsa65-aws-lc

7a6f3a2

	encryption_algorithm: (_serialization.KeySerializationEncryption),
	encryption_algorithm: _serialization.KeySerializationEncryption,

Conversation

DarkaMaul commented Mar 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alex commented Mar 2, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

abbra commented Mar 5, 2026

Uh oh!

alex commented Mar 5, 2026

Uh oh!

abbra commented Mar 5, 2026

Uh oh!

reaperhulk commented Mar 5, 2026

Uh oh!

abbra commented Mar 5, 2026

Uh oh!

alex left a comment

Choose a reason for hiding this comment

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!

Uh oh!

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!

Uh oh!

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!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

DarkaMaul Mar 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

DarkaMaul Mar 13, 2026 •

edited

Loading