DSA: `Verifier` trait not implemented

[Geobert]

Hi,

I'm in a case where I need to verify a signature done on a whole &[u8] rather than a digest and I see that the relevant method is in the Verifier trait but it is not implemented anywhere in the dsa crate.

Is that an oversight or it is something just waiting for a contribution? Or am I missing something?

Regards,

[aumetra]

If you have a while message aggregated inside a byte slice and you want to verify it, you can do the following (replace Sha1 with whatever hashing algorithm you use):

let is_valid = verifying_key.verify_digest(Sha1::new_with_prefix(data)).is_ok();

This could maybe be added as to the documentation as reference.

An implementation of the Verifier trait would do roughly the same thing but default to the preferred hashing algorithm for the signature scheme. DigestVerifier is more flexible and lets you choose the hashing algorithm you want to use.

[Geobert]

Fair enough, I have to add dsa support after I've done ed25519 and the latter had verify so that confused me.

Thanks a lot for your answer!

[tarcieri]

Both sets of traits can be implemented. We should do both unless there’s a complication I’m not thinking of.

[aumetra]

There shouldn't be any complications. The preferred hashing algorithm for DSA is SHA-1, if I'm not mistaken?

[tarcieri]

Ugh, well at the very least that should be feature-gated due to the insecurity of SHA-1.

Looking for relevant RFCs, I see a lot of Internet-Drafts to update the default hash algorithm for DSA, but none of them actually accepted as standards-track RFCs, e.g. draft-rsa-dsa-sha2-256 which became draft-ietf-curdle-rsa-sha2(RSA-only) and eventually RFC8332.

[lumag]

RFC 5754 defines DSA with SHA-224 and SHA256.

[cobratbq]

I had a quick look at this one. It seems RFC 5754 assumes an identifier is included to indicate what hash algorithm was used. So for a plain signature as used for Signer and Verifier this would be an issue. If DSA is used with SHA-1 by default, but then this is disallowed, considered unsafe for many cases. So any choice for the implementation of Signer and Verifier is rather arbitrary IIUC. (And, if the default changes at some later point, implementations that upgrade will suddenly find themselves operating with different parameters, which may be a source of problems in itself, especially with interop.)
update So, I guess the question is, is such an implementation desirable?
update I am rereading, because I feel like I am missing something. Is the idea to have the generic type as part of the Signature-type, such that Signer and Verifier can derive the hashing algorithm automatically?

[lumag]

I'd follow what was done for the RSA crate: turn the Digest into the generic type argument for the Signer and Verifier implementations:

pub struct Signature {...}
impl signature::Signature for Signature {....}
pub struct SigningKey<D> where D: Digest {...}
impl<D> RandomizedSigner<Signature> for SigningKey<D> where D: Digest {....}
impl<D> RandomizedDigestSigner<Signature> for SigningKey<D> where D: Digest {....}
#[cfg(feature = "hazmat")]
impl<D> RandomizedPrehashSigner<Signature> for SigningKey<D> where D: Digest {....}

[lumag]

In other words: let the caller code determine used digest algo and pass it as a generic argument.

[tarcieri]

@lumag yeah exactly, if I'm reading RFC 5754 correctly it uses a similar OID-based approach to RSA, so we can do the exact same thing and query the OID via AssociatedOid.

I would recommend SHA-256 as the default, as SHA-1 is insecure.

[cobratbq]

'd follow what was done for the RSA crate: turn the Digest into the generic type argument for the Signer and Verifier implementations: [..]

This does mean that, within the same application, a produced Signature can be handled incorrectly by lack of type-safety. Acknowledged Granted, this is not the most common use-case, still.

[tarcieri]

@cobratbq I don't follow your complaint. You're arguing that using a generic parameter somehow reduces type safety? Safety around what, and compared to what alternative?