Cannot produce correct ECDSA signature about elliptic-curves HOT 7 CLOSED

So to confirm, the issue is that you are not generating an identical signature to bitcoin-core/libsecp256k1, correct?

Does the signature still verify?

One possible cause is how libsecp256k1 implements RFC6979 deterministic generation of the ECDSA k value: it uses Keccak256 to hash the message, but then uses HMAC-SHA-256 to derive k.

By default k256::ecdsa::recoverable::Signature will use Keccak256 for both.

If that's really the issue, it's possible although a bit involved to wire everything up to use Keccak256 for message hashing, and SHA-256 for computing k. However, note that this doesn't really accomplish anything other than producing the same signature for producing the same signature's sake. Both signatures will still verify.

from elliptic-curves.

The first issue is indeed that the signature is not identical, yes.

I want to test a bit more with Ethereum transactions, because I might have spotted issues there as well, but cannot say for sure now.

If that helps, I tried with web3py (following this) and it produces the same signature as secp256k1.

from elliptic-curves.

If you really want to compute an identical signature, you'll need to use the SignPrimitive trait.

I haven't verified this actually works, but it should be roughly the following:

use k256::{
    ecdsa::hazmat::{SignPrimitive, rfc6979_generate_k},
    elliptic_curve::ops::Reduce,
    NonZeroScalar, Secp256k1, U256
};
use sha2::Sha256;
use sha3::Keccak256;

// Get `NonZeroScalar` for the signing key somehow
let secret_key = NonZeroScalar::new(...);

// Get message to be signed somehow
let msg = b"...";

let z = <Scalar as Reduce<U256>>::from_be_digest_reduced(Keccak256::new_with_prefix(msg));
let k = rfc6979_generate_k::<Secp256k1, Sha256>(&secret_key, &z, &[]);
let (signature, recid) = secret_key.try_sign_prehashed(&k, z)?;

from elliptic-curves.

Got it, thank you very much.

I will test a bit more and get back here, but at least I understand why the signature "appears to be" different.

from elliptic-curves.

If that works, I can potentially tweak the implementation in k256 to do that by default, although it's a bit silly that it's using two different hash functions

from elliptic-curves.

Confirmed everything is good as it is. The signatures are indeed different (and thank you for the explanation about why that's the case) but both work just fine for all purposes I could test.

Thanks again, I will close the issue.

from elliptic-curves.

@MicheleMinelli see how we solved it with a Sha256Proxy here gakonst/ethers-rs#975 (I tried to remove it in the PR but ended up back to the same problem)

from elliptic-curves.