[PSQ] Allow using Classic McEliece for PQ KEM #1108

jschneider-bensch · 2025-08-20T09:03:15Z

This PR does three things:

Clean up, some renaming and more documentation for more of the new PSQ protocol.
Move the old PSQ code to a feature-guarded v1 module, with the exception of some of the Classic McEliece code.
Introduce an abstraction for PQ KEM keys, which allows to use either ML-KEM 768 or Classic McEliece 460896f as the PQ KEM.

If you want I can separate 1. and 2. into their own PR, so the changes relating to 3. become more clear.

In terms of possible "configurations" for 3. I went the simplest option, i.e. an initiator can have either an ML-KEM or CMC longterm public key of the responder, and the responder can have either an ML-KEM or CMC key pair. If there is a mismatch, i.e. the initiator sends a registration message for which the responder does not have a matching decapsulation key, then the responder will ignore that message and return to its initial state.

TODO

Ciphersuite builder
Test configuration mismatch

franziskuskiefer

Just some early thoughts

franziskuskiefer · 2025-08-20T13:26:40Z

libcrux-psq/Cargo.toml

    "mceliece460896f",
    "zeroize",
-], optional = true }
+]}


Shouldn't this still be optional?

Good question! I would like it to be, but I built the PQ KEM selection with an enum now, and that would then have to be non_exhaustive, no?
I recall now we had a similar situation in the original PSQ and then resolved to do this with a commonly implemented trait, instead of an enum. Ideally that would be one of the KEM traits from libcrux-traits... I'll see if I can implement that for the CMC wrapper here.

libcrux-psq/Cargo.toml

franziskuskiefer · 2025-08-20T13:27:56Z

libcrux-psq/Cargo.toml

 [features]
-classic-mceliece = ["dep:classic-mceliece-rust", "rand_old"]
+legacy = []
+# classic-mceliece = ["dep:classic-mceliece-rust", "rand_old"]


Should this go back in?

Yes, I temporarily disabled that too work on the new version as if CMC was unconditionally included, but in any case the old protocol needs the feature.

franziskuskiefer · 2025-08-20T13:40:31Z

libcrux-psq/src/handshake/responder.rs

+        g_xy: &DHSharedSecret::derive(responder_ephemeral_ecdh_sk, initiator_ephemeral_ecdh_pk)?,
+    };
+
+    AEADKey::new(&responder_ikm, tx2).map_err(|e| e.into())


? call into for you. So something like this would work as well.

Suggested change

AEADKey::new(&responder_ikm, tx2).map_err(|e| e.into())

Ok(AEADKey::new(&responder_ikm, tx2)?)

franziskuskiefer · 2025-08-20T13:41:23Z

libcrux-psq/src/handshake/pqkem.rs

+
+impl<'a> PQPublicKey<'a> {
+    /// Encapsulate a PQ-shared secret towards the given PQ-KEM public key
+    pub(crate) fn encapsulate(&self, rng: &mut impl CryptoRng) -> (PQCiphertext, PQSharedSecret) {


You should add lifetimes here to avoid warnings.

franziskuskiefer · 2025-08-20T14:45:04Z

libcrux-psq/src/handshake/pqkem.rs

+#[repr(u8)]
+/// A PQ-KEM key encapsulation
+pub enum PQCiphertext {
+    MlKem768(MlKem768Ciphertext),


This is pretty bad for the CMCE ciphertext (156 vs 1088). But maybe that's fine? Or would it make sense to use references here as well?

franziskuskiefer

Some thoughts

franziskuskiefer · 2025-08-21T06:22:24Z

libcrux-psq/benches/psq_v2.rs

    // External setup
    let responder_ecdh_keys = DHKeyPair::new(&mut rng);
-    let responder_pq_keys = PQKeyPair::new(&mut rng);
+    let responder_pq_keys = libcrux_ml_kem::mlkem768::rand::generate_key_pair(&mut rng);


Should the into once happen up here already?

franziskuskiefer · 2025-08-21T06:25:16Z

libcrux-psq/src/handshake/builder.rs

+    }
+
+    /// Set the long-term PQ key pair.
+    pub fn longterm_pq_keys(mut self, longterm_pq_keys: impl Into<PQKeyPair<'a>>) -> Self {


We should make the API consistent. The DH above gets just a reference. We should pick a style and stick to it for both types of keys.

franziskuskiefer · 2025-08-21T06:29:58Z

libcrux-psq/tests/query.rs

    let responder_ecdh_keys = DHKeyPair::new(&mut rng);

-    let responder_pq_keys = PQKeyPair::new(&mut rng);
+    let responder_pq_keys = libcrux_ml_kem::mlkem768::rand::generate_key_pair(&mut rng);


Same comment as for the builder below. We should pick a style for both. Here in the call site we just see the difference as well.
I think either could be fine. Either a generic key_gen with an algorithm identifier, or explicitly generating the keys. But I think I like one function for all a little better.

franziskuskiefer · 2025-08-21T06:34:52Z

libcrux-psq/src/handshake/builder.rs

+        self
+    }
+
+    /// Set the inner AAD.


Somewhat unrelated to this PR but I think the aad setters need more documentation to tell the user what the outer and inner aads are.

libcrux-psq/src/handshake/builder.rs

jschneider-bensch · 2025-09-17T14:28:10Z

I've changed the proposal here to use a trait mechanism for implementing ciphersuites. This makes it easier to pull out Classic McEliece into a non-default feature.

The downside is that in the way I've implemented it here, we need to pre-serialize the PQ encapsulation, to make the HandshakeMessage types oblivious to the used ciphersuite and we need to do the same with the PQ encapsulation key in another place, since we don't yet have a blanket impl of Serialize for Option<&'a T> from T: Serialize. I tried getting around this by introducing a separate associated type for the reference to the encapsulation key, that would also require a Serialize bound, but could not get it to work. At some point I needed to go from Option<C::EncapsulationKey> to Option<C::EncapsulationKeyRef> and I couldn't figure out which (if any) bounds would allow me to do that.

One more thing that is missing here is a builder for the ciphersuites, so now they are statically constructed in the tests.

franziskuskiefer reviewed Aug 20, 2025

View reviewed changes

franziskuskiefer reviewed Aug 21, 2025

View reviewed changes

franziskuskiefer assigned jschneider-bensch Aug 22, 2025

franziskuskiefer mentioned this pull request Sep 4, 2025

[PSQ] Meta Issue #1031

Open

jschneider-bensch and others added 14 commits September 30, 2025 15:04

Rename items

5514de0

Move items; feature-gate legacy protocol

e99684b

Separate Classic McEliece from legacy PSQ

3888c2e

Change PQKEM structs to enums

0185b78

WIP Classic McEliece

829f86a

Allow Classic McEliece for PQ KEM

9ca0125

Revert changes to bindings

598b5e8

psq: legacy -> v1

874ee1d

psq: fix lints

b0ea62f

WIP

f125dc5

still wip

640260f

Trait-based ciphersuites

a19b02d

Format

f16931a

Revert sys bindings

8658ea5

jschneider-bensch force-pushed the jonas/psq-config branch from 97daa4c to 8658ea5 Compare September 30, 2025 13:04

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

[PSQ] Allow using Classic McEliece for PQ KEM #1108

[PSQ] Allow using Classic McEliece for PQ KEM #1108

Uh oh!

jschneider-bensch commented Aug 20, 2025 •

edited

Loading

Uh oh!

franziskuskiefer left a comment

Uh oh!

franziskuskiefer Aug 20, 2025

Uh oh!

jschneider-bensch Aug 21, 2025 •

edited

Loading

Uh oh!

Uh oh!

franziskuskiefer Aug 20, 2025

Uh oh!

jschneider-bensch Aug 21, 2025

Uh oh!

franziskuskiefer Aug 20, 2025

Uh oh!

franziskuskiefer Aug 20, 2025

Uh oh!

franziskuskiefer Aug 20, 2025

Uh oh!

franziskuskiefer left a comment

Uh oh!

franziskuskiefer Aug 21, 2025

Uh oh!

franziskuskiefer Aug 21, 2025

Uh oh!

franziskuskiefer Aug 21, 2025

Uh oh!

franziskuskiefer Aug 21, 2025

Uh oh!

Uh oh!

jschneider-bensch commented Sep 17, 2025

Uh oh!

Uh oh!

	AEADKey::new(&responder_ikm, tx2).map_err(\|e\| e.into())
	Ok(AEADKey::new(&responder_ikm, tx2)?)

[PSQ] Allow using Classic McEliece for PQ KEM #1108

Are you sure you want to change the base?

[PSQ] Allow using Classic McEliece for PQ KEM #1108

Uh oh!

Conversation

jschneider-bensch commented Aug 20, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

franziskuskiefer left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jschneider-bensch Aug 21, 2025 • 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!

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!

franziskuskiefer left a comment

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!

jschneider-bensch commented Sep 17, 2025

Uh oh!

Uh oh!

jschneider-bensch commented Aug 20, 2025 •

edited

Loading

jschneider-bensch Aug 21, 2025 •

edited

Loading