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

low/high-S option for P-256 (secp256r1) ECDSA signatures? #759

Open
snarfed opened this issue Aug 7, 2023 · 1 comment
Open

low/high-S option for P-256 (secp256r1) ECDSA signatures? #759

snarfed opened this issue Aug 7, 2023 · 1 comment

Comments

@snarfed
Copy link

snarfed commented Aug 7, 2023

Hi! First off, thank you so much for building and maintaining pycryptodome. It's great!

I'm using it to manage keys and signatures for an AT Protocol implementation. They note that ECDSA signatures aren't always deterministic are malleable, and they try to avoid that by requiring signatures with both secp256r1 and secp256k1 curves to use the "low-S" variant, which is evidently formalized in BIP-62.

Are you all aware of these variants? Do you know which variant pycryptodome currently generates, if either? Any chance we could get an option to DSS.new or nearby to specify the variant?

Thanks in advance!

@snarfed
Copy link
Author

snarfed commented Aug 7, 2023

Relevant discussion from the ATProto Discord chat:

basically, ecdsa signing relies on the signer picking a secret random value "k", which has to be unique for each message that's signed (otherwise an attacker can recover the private key!).
and if your k is truly random then your signatures will be non-deterministic (i.e. different each time, even if you're signing the same data with the same key)
but the deterministic algorithms ensure that it's a function of the message being signed, and the privkey, rather than actually random
and the signatures themselves are a pair of integers, (r, s)
and it just so happens that if (r, s) is a valid signature, (r, -s) is also a valid signature
and low-s is just a way of making sure that only one of those is actually valid, by arbitrarily saying that the lower of the two s values is canonically correct

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

No branches or pull requests

1 participant