Skip to content
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

Open
wants to merge 23 commits into
base: master
Choose a base branch
from

Conversation

baloo
Copy link
Member

@baloo baloo commented Feb 16, 2025

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.

@baloo baloo marked this pull request as draft February 16, 2025 08:50
@baloo
Copy link
Member Author

baloo commented Feb 16, 2025

cc @aumetra

@aumetra
Copy link
Contributor

aumetra commented Feb 16, 2025

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)

@baloo
Copy link
Member Author

baloo commented Feb 16, 2025

No need to apologize! Please take care.
That was only to keep you updated on the progress and let you chime in as needed.

If there are specific things you wanted to be taken care of, please let me know I'd be happy to.

@baloo
Copy link
Member Author

baloo commented Feb 17, 2025

out of the last 3 tests that still fail:

  • sign_message: that one needs the vectors to be adjusted, we're switching the backend and by doing so the primes we get from the RNG are different because their generation is now different.
  • signer_verifier_signature: that one is a precision that needs to be adjusted.
  • verify_signature: I'm not quite sure yet.

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.

@baloo baloo force-pushed the baloo/dsa/crypto-bigint branch 2 times, most recently from a5b6804 to fde178e Compare February 18, 2025 05:58
@aumetra
Copy link
Contributor

aumetra commented Feb 19, 2025

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.

Seems like even rsa did the same thing. Just via the .widen method which is, I guess, a newer method that didn't exist when I started this PR a year ago

@aumetra
Copy link
Contributor

aumetra commented Feb 19, 2025

Scratch that, it existed, I just didn't see it at that time

@tarcieri
Copy link
Member

@baloo the precision aspect is definitely a bit tricky. num-bigint does it automatically, however this leads to variable-time operation depending on the value’s precision which is unsuitable for private key operations

@baloo
Copy link
Member Author

baloo commented Feb 19, 2025

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

@baloo baloo force-pushed the baloo/dsa/crypto-bigint branch 3 times, most recently from 26e40ac to 03f4d7a Compare March 2, 2025 07:04
@baloo
Copy link
Member Author

baloo commented Mar 2, 2025

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.

@aumetra
Copy link
Contributor

aumetra commented Mar 2, 2025

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

@baloo baloo force-pushed the baloo/dsa/crypto-bigint branch 4 times, most recently from a481afb to 71639a3 Compare March 3, 2025 02:54
Copy link
Member Author

@baloo baloo left a 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.

Comment on lines 121 to 124
// 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();
Copy link
Member Author

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

Comment on lines 135 to 136
// TODO(baloo): is there any way S could be zero here?
let s = NonZero::new(s).unwrap();
Copy link
Member Author

@baloo baloo Mar 3, 2025

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?

@baloo baloo marked this pull request as ready for review March 3, 2025 03:53
@baloo baloo force-pushed the baloo/dsa/crypto-bigint branch 3 times, most recently from c0a9f41 to 5fd1ebc Compare March 3, 2025 03:57
Comment on lines 25 to +38
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"
);
Copy link
Member Author

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?

Copy link
Contributor

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.

@tarcieri
Copy link
Member

tarcieri commented Mar 9, 2025

@baloo this one could actually use a rebase

@baloo baloo force-pushed the baloo/dsa/crypto-bigint branch from e8a249b to 56c953b Compare March 9, 2025 19:39
@baloo
Copy link
Member Author

baloo commented Mar 9, 2025

This probably should include tests stretching the bit precision of a signature to test against panic.
Maybe proptests would be a good fit?

@tarcieri
Copy link
Member

tarcieri commented Mar 9, 2025

Yes proptests would be good.

I need to pull this down and benchmark it but getting the precisions right has been a challenge in rsa. Did performance regress significantly?

@baloo
Copy link
Member Author

baloo commented Mar 9, 2025

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants