Missing signatures

[newpavlov]

• ML-DSA / Dilithium
• SLH-DSA
• DSA
• ECDSA
  • NIST P-256 (via p256)
  • NIST P-384 (via p384)
  • NIST P-521 (via p521)
  • secp256k1 (via k256)
• Ed25519
• Ed448

[link2xt]

DSA - Requested here: rpgp/rpgp#56

[heisen-li]

Is DSA not implemented yet? I can try to add.

[tarcieri]

Nobody's working on DSA. You can go for it. Edit: implemented!

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

[lumag]

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.

[adamvm]

During build automata with rust nightly:

Compiling ed25519 v1.3.0 (https://github.com/RustCrypto/signatures.git?tag=ed25519/v1.3.0#8282fcaf)
error[E0405]: cannot find trait Signature in crate signature
--> /home/ami/.cargo/git/checkouts/signatures-a6df6df1cc32e789/8282fca/ed25519/src/lib.rs:349:17
|
349 | impl signature::Signature for Signature {
| ^^^^^^^^^ not found in signature

For more information about this error, try rustc --explain E0405.
error: could not compile ed25519 (lib) due to previous error
warning: build failed, waiting for other jobs to finish...

[tarcieri]

nightly is expected to break in ways that have nothing to do with our crates, nor can we do anything to fix them

[tarcieri]

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 ml-kem.

[cothan]

Hi, I'm interested in implementing ML-DSA.

[tarcieri]

cc @bifurcation

[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 ml-kem crate has good framework to adapt.

[tarcieri]

Ideally I'd hope there can be some reuse / shared code between ml-kem and ml-dsa, but I'm not sure the best way to structure that, especially since they're split across repos

[bifurcation]

The part I would have the most hope for is the linear algebra bits (algebra.rs in ml-kem), since those seem pretty much the same aside from the prime in use. Even then, you would have to make these operations generic over the prime, and probably over the storage class as well -- the ML-KEM prime fits in 12 bits, while the ML-DSA prime requires 24 bits.

[cothan]

I agree. I read through the code and see that the algebra.rs is the one that I can reuse.
I'll try to read the rest of the ml-kem to see if we can reuse code.

[marija-mijailovic]

Hi, I am interested in collaborating on implementation ML-DSA. Is there a specific way or task I could focus on to integrate best?

[tarcieri]

@cothan any thoughts on a potential collaboration?

[cothan]

hi @marija-mijailovic , thank you for your interested. I will invite you to my private repo, so we can discuss further.

[bifurcation]

@tarcieri Might be good to add SLH-DSA / FIPS 205 to the list? I might be willing to take a hack at that.

[tarcieri]

@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!

[ranjithravitk]

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?

[tarcieri]

@ranjithravitk Diffie-Hellman is a key exchange mechanism. We have a separate repo for that over here: https://github.com/rustcrypto/kems

[aumetra]

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?

[tarcieri]

Yes, it would be great to have an ElGamal implementation but like RSA it probably deserves its own repo

[ranjithravitk]

@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.

[tarcieri]

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?)

[ranjithravitk]

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.

[tarcieri]

I made a new repo for ElGamal and opened a planning issue here: RustCrypto/ElGamal#1

[iquerejeta]

What about adding Schnorr signatures?

[tarcieri]

We have an implementation of BIP340 Schnorr in the k256 crate.

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.

[iquerejeta]

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.

[tarcieri]

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.