-
Notifications
You must be signed in to change notification settings - Fork 216
signature
: add MultipartSigner
and MultipartVerifier
#1880
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
Conversation
If we are to support such messages, we probably should do it in separate methods or maybe even in a separate trait. |
I will go ahead and move it into a separate method then. I don't think a separate trait is necessary as the |
signature
: use &[&[u8]]
for messagessignature
: use Iterator<Item = AsRef<[u8]>
for messages
I went ahead and added a Will update the other PRs today and see how it looks before moving this out of draft again. |
signature
: use Iterator<Item = AsRef<[u8]>
for messagessignature
: use Iterator<Item: AsRef<[u8]>
for messages
This adds a lot of code surface but really doesn’t add any new functionality. We already support IUF signing via Where I guess this could maybe help are for constructions that don’t fit into a strictly IUF API like streaming Ed25519 (non-Ed25519ph) or ML-DSA with external mu. But it’s unclear to me we can build traits which actually abstract over such APIs. If we could, I guess this would be close, but that should probably be the design rationale. |
Also note that the original proposed |
FWIW, here's discussion on this sort of API for Ed25519. It was actually removed from this PR, but prior to that, it was suggested to use |
The intention is not a streaming interface, but a streaming interface would address the problem here indeed as well.
Ah right ... I forgot why I had planned it with So if the approach with Just to clarify: the intention here is to support non-contiguous byte slices for Ed25519/448, ML-DSA and SLH-DSA. |
I agree with the earlier comments that this should be a new trait, like I think it would probably also be good to get everything prototyped in PRs to those crates first before we merge, so we know it's actually a good abstraction. |
I added support for ML-DSA and SLH-DSA in RustCrypto/signatures#981. I'm happy to make a PR to the Just my 2¢: if you take a look at RustCrypto/signatures#981, the changes are pretty minimal. I really don't believe that going from |
@daxpedda if you look at dalek-cryptography/curve25519-dalek#735, the same cannot be said of Ed25519. I don't want to force signature implementations to have to implement this interface as their only possible choice. We can't even guarantee this interface is possible for all signature algorithms (at least in an unbuffered, |
signature
: use Iterator<Item: AsRef<[u8]>
for messagessignature
: use &[&[u8]]
for messages
Alright, that was easier than expected, so let me say this:
I still think it should be a separate trait to keep it out of the way. |
Sounds good, on it! |
Let me know what you think. We may want to implement traits on demand, for OPAQUE I will only need |
Should I add a |
I went ahead and did both: removed |
Implementation for ML-DSA and SLH-DSA done in RustCrypto/signatures#982. I hope that dalek-cryptography/curve25519-dalek#763 was sufficient, so I will wait until we are ready to upgrade RustCrypto dependencies there before I make a PR. Probably dalek-cryptography/curve25519-dalek#735 will be relevant as well, as that could be used to implement the Let me know if there is something else you want me to implement/explore/discuss. |
signature
: use &[&[u8]]
for messagessignature
: add MultiPartSigner
and MultiPartVerifier
@daxpedda regarding |
FYI: the blanket implementation didn't work because I can't bind Will go ahead and make the PR in |
Yeah, just go ahead and hand write impls for now |
signature
: add MultiPartSigner
and MultiPartVerifier
signature
: add MultipartSigner
and MultipartVerifier
Done: RustCrypto/signatures#982. Let me know if you want me to implement it for any other specific crate or for the complete rest. |
I went ahead and implemented it for the remaining crates. |
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.
Can tentatively approve this, but it would be good to see it integrated into ed25519-dalek
as well before a final release. It doesn't look like it will be a problem.
Implementation of `MultipartSigner` and `MultipartVerifier` added in RustCrypto/traits#1880.
This PR adds new traits for multipart messages:
MultipartSigner
,RandomizedMultipartSigner
,RandomizedMultipartSignerMut
andMultipartVerifier
.The idea here is to allow non-contiguous bytes to be passed, which is necessary when the message has to be constructed from multiple sources without wanting to allocate memory for a contiguous message. E.g. for
no_std
environments or when the message is rather big but pre-hashing is not applicable, e.g. PureEdDSA, ML-DSA or SLH-DSA.I know this is a rather big breaking change, so let me know what you think!
These new traits can be implemented by a bunch of crates:
ecdsa
: ImplementMultipartSigner/Verifier
signatures#982ml-dsa
: ImplementMultipartSigner/Verifier
signatures#982slh-dsa
: ImplementMultipartSigner/Verifier
signatures#982bign256
: ImplementMultipartSigner/Verifier
elliptic-curves#1221sm2
: ImplementMultipartSigner/Verifier
elliptic-curves#1221k256
: ImplementMultipartSigner/Verifier
elliptic-curves#1221dsa
: ImplementMultipartSigner/Verifier
signatures#982lms
: ImplementMultipartSigner/Verifier
signatures#982rsa
: ImplementMultipartSign/Verify
RSA#525ed25519-dalek
: ImplementMultipartSigner/Verifier
dalek-cryptography/curve25519-dalek#764Resolves RustCrypto/signatures#959.