-
Notifications
You must be signed in to change notification settings - Fork 26
Signature traits #1080
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Signature traits #1080
Conversation
d7ee4d0
to
e0ada6b
Compare
There was a problem hiding this 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.
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. |
There was a problem hiding this 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
TODO
s 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?
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:
|
085d432
to
238ffd0
Compare
traits/src/signature/slice.rs
Outdated
#[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. |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this 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.
7c1e998
to
1ee2dae
Compare
Converting this to a draft for now. See #1107. |
There was a problem hiding this 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!
03c79fb
to
9bff06d
Compare
I added an initial implementation of |
1a1e602
to
ecc056f
Compare
There was a problem hiding this 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.
ebe3469
to
d632d86
Compare
6304db4
to
1c65231
Compare
There was a problem hiding this 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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this 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"))] |
There was a problem hiding this comment.
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: (), |
There was a problem hiding this comment.
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; |
There was a problem hiding this comment.
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
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
)