-
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: migrate to crypto-bigint
#906
base: master
Are you sure you want to change the base?
Conversation
cc @aumetra |
Apologies, I was a bit absent lately. I'll have a look when I get the time (which should be in like two hours at max) |
No need to apologize! Please take care. If there are specific things you wanted to be taken care of, please let me know I'd be happy to. |
out of the last 3 tests that still fail:
Overall having to adjust precisions seems to be ... inefficent? error-prone? I guess there is a way better method for doing that. I need to have a look at RSA how they did it there. |
a5b6804
to
fde178e
Compare
Seems like even |
Scratch that, it existed, I just didn't see it at that time |
@baloo the precision aspect is definitely a bit tricky. |
Oh I understand why it's done! I'm just not sure I know what I'm doing [insert here the picture of a dog]. |
26e40ac
to
03f4d7a
Compare
okay, it's definitely on the ugly side, but tests do pass \o/ I think I got the hang of it, I think I can clean things up from there, but ... tomorrow. |
Nice! I mean I have a few hours to kill today, too, so I can go ahead and try to clean up some things, too. I'll PR it into your fork when I get to it |
a481afb
to
71639a3
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those two NonZero
I'm not sure about.
dsa/src/signing_key.rs
Outdated
// TODO(baloo): is there any way R could be zero here? Could it be any reason for K to be | ||
// one? | ||
let r_short = NonZero::new(r_short).unwrap(); | ||
let r = NonZero::new(r).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure about this unwrap, isn't there a way for r = g.modpow(k, p) % q
to be zero?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IIRC r
and s
should neither be ever zero, and if they are it's an invalid signature. So panicking here is fine since AFAIK there would have had to be a cosmic ray or something hitting the CPU register/memory chip for that to exist.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh right, that ties to the k
value computed in the secret_number
and secret_number_rfc6979
!
That would then be a bug and a panic might be in order.
dsa/src/signing_key.rs
Outdated
// TODO(baloo): is there any way S could be zero here? | ||
let s = NonZero::new(s).unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly here, s
could be zero?
c0a9f41
to
5fd1ebc
Compare
const MESSAGE_SIGNATURE_CRATE_ASN1: &[u8] = &[ | ||
0x30, 0x2C, 0x02, 0x14, 0x45, 0x1D, 0xE5, 0x76, 0x21, 0xD8, 0xFD, 0x76, 0xC1, 0x6F, 0x45, 0x4E, | ||
0xDE, 0x5F, 0x09, 0x79, 0x76, 0x52, 0xF3, 0xA5, 0x02, 0x14, 0x53, 0x60, 0xE6, 0xB7, 0xF0, 0xCF, | ||
0xAE, 0x49, 0xB1, 0x58, 0x5C, 0xCF, 0x5F, 0x3F, 0x94, 0x49, 0x21, 0xA0, 0xBF, 0xD2, | ||
0x30, 0x2d, 0x2, 0x14, 0x4, 0x23, 0xc3, 0xf1, 0xa5, 0x15, 0x65, 0xe5, 0xcc, 0x30, 0xdd, 0x55, | ||
0x96, 0x27, 0x30, 0xfb, 0x42, 0xf9, 0x2a, 0x6b, 0x2, 0x15, 0x0, 0x95, 0xd9, 0x42, 0xc2, 0xab, | ||
0xe7, 0x62, 0x49, 0x80, 0x4f, 0x53, 0xf1, 0x37, 0x57, 0x81, 0x7b, 0xea, 0x71, 0xc9, 0x2f, | ||
]; | ||
|
||
/// Message signed by OpenSSL using the keys generated by this CSPRNG | ||
/// | ||
/// This signature was generated using the SHA-256 digest | ||
const MESSAGE_SIGNATURE_OPENSSL_ASN1: &[u8] = &[ | ||
0x30, 0x2C, 0x02, 0x14, 0x6D, 0xB3, 0x8E, 0xAF, 0x97, 0x13, 0x7E, 0x07, 0xFF, 0x24, 0xB8, 0x66, | ||
0x97, 0x18, 0xE1, 0x6F, 0xD7, 0x9A, 0x28, 0x2D, 0x02, 0x14, 0x47, 0x8C, 0x0B, 0x96, 0x51, 0x08, | ||
0x08, 0xC8, 0x34, 0x9D, 0x0D, 0x41, 0xC7, 0x73, 0x0F, 0xB5, 0x9C, 0xBB, 0x00, 0x34, | ||
]; | ||
const MESSAGE_SIGNATURE_OPENSSL_ASN1: &[u8] = &hex!( | ||
"302e 0215 0092 4523 9462 f59b 5936 d355 | ||
8b16 8dbb 0915 7ba1 5302 1500 9d8d 7aa7 | ||
02a6 2dde 1975 e9f2 a20c 73b4 7dd3 0912" | ||
); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The behavior of Components::generate
changed because of the switch to crypto-bigint (and crypto-primes). This makes the "deterministic" private key used for test change. And as a result, makes the signatures change.
I don't believe we offered any guarantee towards the stability of the Component::generate
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, we didn't make any guarantees. The only guarantee we provided was "it outputs something that works".
If some code relies on this staying the same it's really fragile anyway, since they'd have to use the same algorithms to generate primes and factors, which can differ between implementations. So yeah, this should be fine.
b715031
to
e8a249b
Compare
@baloo this one could actually use a rebase |
required because of crypto-bigint
e8a249b
to
56c953b
Compare
This probably should include tests stretching the bit precision of a signature to test against panic. |
Yes proptests would be good. I need to pull this down and benchmark it but getting the precisions right has been a challenge in |
It was pretty bad at some point (tests would take over a minute) but I did not dig why. It works fine now. I did not run a benchmark. |
This is a rebase of #784
There are two commits on top that I think should fix tests. There is a bit of cleanup to do still.