-
Notifications
You must be signed in to change notification settings - Fork 130
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
dsa: Eq is missing for Components, SigningKey and VerifyingKey #881
Comments
Derived |
how so, if there is already |
It doesn't currently impl |
I'm probably missing something obvious, but doesn't /// DSA private key.
///
/// The [`(try_)sign_digest_with_rng`](::signature::RandomizedDigestSigner) API uses regular non-deterministic signatures,
/// while the [`(try_)sign_digest`](::signature::DigestSigner) API uses deterministic signatures as described in RFC 6979
#[derive(Clone, PartialEq)]
#[must_use]
pub struct SigningKey {
/// Public key
verifying_key: VerifyingKey,
/// Private component x
x: Zeroizing<BigUint>,
} |
Oh, I guess it does derive |
Yeah, crypto-bigint will nearly solve it, but correct me if I'm wrong, comparing Component would still short-circuit after the first non-matching struct member, right? /// The common components of an DSA keypair
///
/// (the prime p, quotient q and generator g)
#[derive(Clone, Debug, PartialEq, PartialOrd)]
#[must_use]
pub struct Components {
/// Prime p
p: BigUint,
/// Quotient q
q: BigUint,
/// Generator g
g: BigUint,
} I don't know enough about DSA to know how much of a problem that is security wise... but it does sound like a fun thing for me to try to fix after #906 lands. |
Only |
Short circuiting doesn't matter as long as it isn't on the limbs of the private factor in the signing key, since the components are public knowledge anyway. So after the |
Yep, |
I don't see any internal details that would make an impl/derive invalid
The text was updated successfully, but these errors were encountered: