Skip to content

Conversation

wysiwys
Copy link
Contributor

@wysiwys wysiwys commented Jul 23, 2025

This PR implements the Signature traits.

  • keygen()
  • sign()
  • verify()

Resolves #1034

Includes implementations for:

  • ed25519 (arrayref, slice, owned)
  • libcrux-ml-dsa (owned)
  • ecdsa (arrayref, slice, owned)

@wysiwys wysiwys self-assigned this Jul 23, 2025
@wysiwys wysiwys force-pushed the wysiwys/signature-trait branch from d7ee4d0 to e0ada6b Compare August 11, 2025 14:26
@wysiwys wysiwys marked this pull request as ready for review August 11, 2025 16:41
@wysiwys wysiwys requested review from a team as code owners August 11, 2025 16:41
keks
keks previously requested changes Aug 11, 2025
Copy link
Member

@keks keks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this goes in a good direction, nice!

I am not sure what to best do with the Aux, it looks like it could be confusing to users. I wonder if being a bit less generic could help here.

Otherwise I left a few comments. I have one remark on it but then realize it affects a lot of things: There are a lot of doc comments missing.

@wysiwys
Copy link
Contributor Author

wysiwys commented Aug 12, 2025

Thanks for the review and feedback @keks! I addressed most of the feedback points, and added some comments for the other points.

For the trait organization (specifically how to handle randomness and auxiliary data), I think there is room for improvement, too, and I think there is likely a combination of the different options from our discussion above that will address many of the concerns around ergonomics/complexity. I will take another look at the different combinations of input data we need to support, and look at the pros and cons of different approaches.

Copy link
Collaborator

@jschneider-bensch jschneider-bensch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the traits look good!

I have some comments:

  • There are some TODOs left in different places. Are these for follow-ups, or do you want to address them in this PR?
  • Could you try and add a generic test for some of the APIs, e.g. like with the KEM trait, s.t. we know the implementation works?
  • Could you summarize in the PR description which scheme now implements which APIs? Or are they all covered via blanket impls?

@keks
Copy link
Member

keks commented Aug 13, 2025

What I am wondering is whether our Signature traits should support all uses of context. We also don't support all the features of the blake2 hash (e.g. personalisation or keying of the hash).

We could pretty easily support the use of contexts known at compile time:

  • Add a trait Context { context() -> &'static [u8]; } to the mldsa crate
  • Then impl<Ctx: Context> RandomizedSignature for MlDsa<Ctx>, where we call the context function to get the value
  • The context function should be marked inline(always). Maybe we can define a macro that defines a context struct and implements the trait for it, so the user doesn't forget to set it?

@wysiwys wysiwys requested a review from keks August 18, 2025 09:03
@github-actions github-actions bot dismissed keks’s stale review August 18, 2025 09:03

Review re-requested

@wysiwys wysiwys force-pushed the wysiwys/signature-trait branch from 085d432 to 238ffd0 Compare August 18, 2025 12:11
#[macro_export]
macro_rules! impl_verify_slice_trait {
($type:ty => $vk_len:expr, $sig_len:expr, $verify_aux:ty, $verify_aux_param:tt) => {
/// The [`mod@slice`] version of the Verify trait.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't link correctly for me. Maybe something like [slice](libcrux_traits::signature::slice) would work?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for catching that! I updated the link to the suggestion. Could you let me know if the link works correctly on your side now?

keks
keks previously requested changes Aug 18, 2025
Copy link
Member

@keks keks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, even RSA is looking better and better :)

I noticed some files had weird whitespace. Did you run rustfmt? I also found a bunch of TODOs that note that something doesn't show up in documentation. What exactly isn't showing up? The comments read like the trait doesn't show up, but that makes sense because the block only contains the impl.

@franziskuskiefer
Copy link
Member

Converting this to a draft for now. See #1107.

@franziskuskiefer franziskuskiefer marked this pull request as draft August 25, 2025 09:13
Copy link
Member

@keks keks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this looks pretty good! I have a few questions on some design details that I would like to discuss before we proceed, but the fundamentals look like they are in place!

@wysiwys wysiwys force-pushed the wysiwys/signature-trait branch from 03c79fb to 9bff06d Compare August 26, 2025 14:51
@wysiwys
Copy link
Contributor Author

wysiwys commented Aug 26, 2025

I added an initial implementation of keygen() to the traits in this PR.

@wysiwys wysiwys force-pushed the wysiwys/signature-trait branch from 1a1e602 to ecc056f Compare September 29, 2025 08:02
@wysiwys wysiwys requested a review from keks September 30, 2025 13:05
@github-actions github-actions bot dismissed keks’s stale review September 30, 2025 13:05

Review re-requested

Copy link
Member

@keks keks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this mostly looks good, just a few nitpicks.

@wysiwys wysiwys marked this pull request as ready for review October 1, 2025 07:24
@wysiwys wysiwys force-pushed the wysiwys/signature-trait branch 2 times, most recently from ebe3469 to d632d86 Compare October 1, 2025 14:29
@keks keks force-pushed the wysiwys/signature-trait branch from 6304db4 to 1c65231 Compare October 2, 2025 13:52
Copy link
Member

@keks keks left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments on my changes

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Somehow sign_mut existed in the instantiations but not in multiplexed. Added so we can impl arrayref

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did a more complicate thing here for bounding the context sizes, because I didn't see a good way to return an error regarding this. This way we use the type system to ensure the error can't happen.

Dynamic contexts already were not supported in this API because we need to be able to determine the context from the type, so I hope that is fine.

@keks keks requested a review from jschneider-bensch October 2, 2025 14:00
Copy link
Member

@franziskuskiefer franziskuskiefer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, a couple thoughts.

Dropping old APIs we do in a separate PR?

@@ -0,0 +1,98 @@
#[cfg(any(feature = "ecdsa", feature = "ed25519", feature = "mldsa"))]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A lib comment up here would be nice with a little info and an example on how to use this.

payload: &[u8],
signing_key: &[U8; SIGNING_KEY_LEN],
signature: &mut [u8; SIGNATURE_LEN],
_aux: (),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Having a useless parameter in the API isn't great. Maybe the aux version should be a different trait? Or maybe traits just make it more complicated than necessary for signatures.

}
};
}
pub use impl_context;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Asking the user to implement these types is a little odd. Also, I'm not sure how well this works for more dynamic contexts?
We could make this slightly different to just have array references and the caller just wraps them. I made a quick example here https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=661ba82dce767334432a31da021307e1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Signature trait
4 participants