-
Notifications
You must be signed in to change notification settings - Fork 111
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
Missing signatures #8
Comments
DSA - Requested here: rpgp/rpgp#56 |
Is DSA not implemented yet? I can try to add. |
It might be good to come up with a plan for how it would be implemented (e.g. what crate dependencies would be used, for example), and ideally try to align with https://github.com/RustCrypto/RSA on some of those decisions |
Adds an initial implementation of DSA (see #8) The following things work when tested against OpenSSL: - The generated keys are valid and can be imported and exported from/to their DER/PEM representation - Signatures generated by this library can be successfully verified - Signatures can be imported and exported from/into their DER representation - Signatures generated by OpenSSL can be successfully imported and verified
GOST digital signature alsorithm is missing. However additional care should be taken while implementing it. The standard is clueless with respect to endianness of the used numbers. The implementation should follow the established practice, rather than blindly following the standard. |
During build automata with rust nightly: Compiling ed25519 v1.3.0 (https://github.com/RustCrypto/signatures.git?tag=ed25519/v1.3.0#8282fcaf) For more information about this error, try |
|
A note about ML-DSA: we now have an ML-KEM implementation at https://github.com/RustCrypto/KEMs/tree/master/ml-kem It would be good for an ML-DSA implementation to share a common core with |
Hi, I'm interested in implementing ML-DSA. |
cc @bifurcation |
Hey @cothan, happy to collaborate on ML-DSA. Especially if you're willing to take the lead :) I haven't looked at ML-DSA much, but my impression is that the algebra is similar to ML-KEM, but the constants are different, as are which bits are public/private. So you'll probably want to change some things, but hopefully the |
Ideally I'd hope there can be some reuse / shared code between |
The part I would have the most hope for is the linear algebra bits ( |
I agree. I read through the code and see that the |
Hi, I am interested in collaborating on implementation ML-DSA. Is there a specific way or task I could focus on to integrate best? |
@cothan any thoughts on a potential collaboration? |
hi @marija-mijailovic , thank you for your interested. I will invite you to my private repo, so we can discuss further. |
@tarcieri Might be good to add SLH-DSA / FIPS 205 to the list? I might be willing to take a hack at that. |
@bifurcation I've been in touch with @trailofbits about contributing an SLH-DSA implementation. They recently contributed an LMS implementation (#801). Good point though, added to the list! |
Hi, I went through the repository and believe that the diffie-hellman key exchange and ElGamal were not implemented. I would like to take a chance at that or is there any reason for not implementing it? |
@ranjithravitk Diffie-Hellman is a key exchange mechanism. We have a separate repo for that over here: https://github.com/rustcrypto/kems |
And ElGamal is in a weird spot, similar to RSA, where it has a signature scheme and an encryption scheme. Wouldn't a separate repo be appropriate here? |
Yes, it would be great to have an ElGamal implementation but like RSA it probably deserves its own repo |
@tarcieri Can I take a look into the ElGamal signature and Elgamal encryption? I will try to come up with its own repo like RSA. |
Yes, though we should definitely have a planning issue for how it should work (e.g. should it be specialized to ECC but generic over elliptic curve groups?) |
I was thinking of a repo with generic ElGamal encryption and signature. we can implement the Elgamal over elliptic curve groups as well inside the repo. And yes, we can use planning issue to understand the design. @tarcieri what do you think about this? Correct me if I am wrong. |
I made a new repo for ElGamal and opened a planning issue here: RustCrypto/ElGamal#1 |
What about adding Schnorr signatures? |
We have an implementation of BIP340 Schnorr in the The question beyond that is: what variant of Schnorr? EdDSA is the most popular one in modern use. Other than that, BIP340 is the only other modern specification I'm aware of. |
Oh, missed BIP340 in k256. I think we could implement that generically, over any curve with a prime number of points (unlike edwards curves, for which EdDSA exist). Don't know if that generic exists though. |
I would be wary to implement BIP340 for elliptic curves other than secp256k1. It's not really defined that way. EdDSA is designed to be useful across multiple twisted Edwards curves, except @RustCrypto has no implementations of those. |
@cothan, bit late to the party but would also be interested in helping out with ML-DSA. Any chance I could be added to your repo to lend a hand to anything? |
It sure would be nice if people worked on ML-DSA in public forks. I have no idea what the status of @cothan's branch is. |
Hi @supinie , I send you invitation to my github repo. I will make the repo public at when some code has landed. |
FYI, I've published some initial crate boilerplate for Edit: PR open with an implementation: #877 |
p256
)p384
)p521
)k256
)The text was updated successfully, but these errors were encountered: