Insight on Default Value Strategy for `auxRand` in Schnorr Signing about noble-curves

[landabaso]

I (might) have identified the problem and will now report it to tiny-secp256k1. I'm documenting it here as well, in case someone encounters this issue in the future.

The behaviour in libsecp256k1 for auxRand === NULL was changed in the following commits:

• 5324f8942dd322448fae6c9b225ecac2854fa7e2
• Pull Request #1002

However, tiny-secp256k1 (might) be using a version of libsecp256k1 prior to these changes?

[paulmillr]

Understood. So, the libraries don't follow the spec. I've opened issues:

guggero/bip-schnorr#32 bitcoin-core/secp256k1#1365

[landabaso]

I just read your conversation with @sipa. Thanks for the feedback.

Given this new information, it's clear the inconsistency in results is not due to libsecp256k1 itself. The discrepancy might be coming from how tiny-secp256k1 (from bitcoinjs-lib) accesses libsecp256k1 or perhaps something else that I've overlooked.

Both tiny-secp256k1 and bip-schnorr return different results when auxRand = Buffer.alloc(32, 0x00) than when it is not passed. This is the reason I have been unable to pass Buffer.alloc(32, 0x00) to @noble to get the same deterministic result. But yes, it is very clear this is not an issue with @noble.

To replicate my findings, you can run the test:

git clone https://github.com/landabaso/sign_schnorr_test.git
cd sign_schnorr_test
npm install
npm run test

I'm still trying to make sense of why this is happening and any insight would be appreciated. Anyway, feel free to close this issue since there is nothing wrong with @noble. Thanks!

[paulmillr]

I think the issue should be reported to tiny-secp256k1. I'm not familiar with its architecture so can't provide a feedback.

[paulmillr]

https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Default_Signing

Using unpredictable randomness additionally increases protection against other side-channel attacks, and is recommended whenever available. Note that while this means the resulting nonce is not deterministic, the randomness is only supplemental to security

In other words, we follow the spec. Are you saying libsecp256k1 does not follow it?

When a randomness is not available, passing a 32-byte all-zeros byte array should be fine. It would also make it deterministic. How does libsecp256k1 compute auxRand? Is it similar to ECDSA RFC6979?

[landabaso]

Thank you for looking into this!

In other words, we follow the spec.

Understood. Indeed, there isn't a problem with this package. My inquiry was more about whether I could use it to replicate the behavior of libsecp256k1.

When a randomness is not available, passing a 32-byte all-zeros byte array should be fine.

I've tried this approach, and while the result is deterministic, it differs from the output of libsecp256k1.

How does libsecp256k1 compute auxRand?

As per the original issue, it was reported that libsecp256k1 produces the same result as the "bip-schnorr" npm package, but differs from the output of noble. I personally ran some tests to verify this report and found it to be accurate—both libsecp256k1 and "bip-schnorr" return the same value when the same input parameters are used (and no auxRand).

To understand how "bip-schnorr" handles auxRand, I looked into their implementation. This line shows how they handle auxRand:

https://github.com/guggero/bip-schnorr/blob/b6479ecf55da1266ae49eac3565bca3a8b1a8832/src/schnorr.js#L32

Based on this, I believe libsecp256k1 follows a similar strategy.

In the meantime, I have updated my package to issue a console warning whenever the resulting signature may not align with the results from tiny-secp256k1, although the signature itself is valid. Thank you again, @paulmillr, for your input!