dsa: implement Signer and Verifier using SHA-256 as default

[cobratbq]

In follow-up of discussion in #520: a minimal implementation for Signer and Verifier using SHA-256 for digests. The issue discusses possible options of introducing the OID, however this is not part of this implementation.

[lumag]

I suppose that it might be better to add a <D: Digest> generic arg.

[cobratbq]

I suppose that it might be better to add a <D: Digest> generic arg.

You are right. I investigated this earlier. There are cascading effects involved, due to currently the generic type being completely absent. I do not want to go there now for its structural changes. It involves some deriving of hash functions from component lengths, for the cases of reading signatures from byte-sequences.

Regardless, those changes are orthogonal in nature, so they need not block this contribution if you are interested.

Incidentally, how do you cope with backwards-incompatible changes? Such as those discussed in #520, and as you mentioned just now.

[tarcieri]

Incidentally, how do you cope with backwards-incompatible changes? Such as those discussed in #520, and as you mentioned just now.

We can bump the minor version, as the crate is still 0.x

That said, you should be able to add a generic digest type parameter with a default of e.g. sha2::Sha256 in a backwards-compatible way.

[cobratbq]

@tarcieri

That said, you should be able to add a generic digest type parameter with a default of e.g. sha2::Sha256 in a backwards-compatible way.

Just checking: you are referring to the use of Sha256 as digest D for DigestSigner etc. right? (That is, not for deterministically signing the prehash according to RFC 6979.)

[tarcieri]

@cobratbq that would be for controlling the digest function used to prehash the message, not for RFC6979 specifically (which is an opaque, internal detail from a user-facing perspective)

[lumag]

@cobratbq I was thinking about Signer and Verifier rather than DigestSigner / DigestVerifier.

[cobratbq]

I do not get how you see this being done: Signer and Verifier effectively rely on DigestSigner and DigestVerifier a-like logic.

• If the generic is introduced in Signature (which I think you do not suggest) then it impacts every aspect of the Signature impl.
• If I modify Signer and Verifier themselves, I would need to update signature which is at version 1.6.4.

[tarcieri]

@cobratbq again, you an add a D: Digest parameter to the SigningKey/VerifyingKey types (not any of the traits)

[lumag]

@cobratbq I took the liberty and sketched a quick & dirty implementation at #560.

[lumag]

Ok, and as we can see, the quick-and-dirty doesn't seem to work.

[tarcieri]

This is fine for now.

I'm going to release this, and then work on the proposed changes for signature v2.0. See: RustCrypto/traits#1141

@cobratbq if you'd like to propose any breaking changes to the traits, this will be the only opportunity in the immediate future to do so.

[cobratbq]

@tarcieri

@cobratbq if you'd like to propose any breaking changes to the traits, this will be the only opportunity in the immediate future to do so.

I don't have anything meaningful right now. My exploration brought me into type-safety-complications, and -- as you know -- these things can be solved in a variety of ways.

One thing to point out for consideration: the ECDSA Signature type have the Digest as generic type for the signature, while you also discussed doing this differently. Is this something you need to standardize? (I don't feel confident enough to propose something myself. However, changing the approach means changing all the ..Signer and ..Verifier interfaces, so now is the time to reconsider.)

[tarcieri]

The ecdsa crate pretty much exclusively relies on PrehashSignature::Digest for the digest type. This keeps the digest pretty much completely out of the way.

What we might consider is redesigning DigestSigner/DigestVerifier, especially now that PrehashSigner/PrehashVerifier are available.

It'd be good to open an issue with the problems you'd like to see solved.

[tarcieri]

@cobratbq ideally what I think would be nice as a pattern for tying the digest algorithm to the signature at the type level is leveraging const generics ala something like:

pub struct Signature<const DIGEST_OID: ObjectIdentifier = sha2::Sha256::OID> { ... }

This allows specifying what algorithm should be used without tying it to a concrete implementation, which makes it possible to plug in things like wrappers for hardware cryptographic accelerators so long as they claim to support the correct OID for a particular algorithm.

You can then bound on e.g. D: Digest + AssociatedOid<OID = sha2::Sha256::OID>