Insight on Default Value Strategy for `auxRand` in Schnorr Signing

[landabaso]

I am currently using the noble library to maintain a Bitcoin package, @bitcoinerlab/secp256k1, that aligns with the interface of tiny-secp256k1 in the bitcoinjs-lib ecosystem. This package is ultimately dependent on the bitcoin-core/secp256k1 library.

Recently, an issue was reported in our package related to the inconsistency of Schnorr signatures when auxRand is not passed.

Upon investigation, I noted a discrepancy in the strategy used to handle auxRand when it's not passed. In noble-curves and noble-secp256k1 1.7, auxRand defaults to a random value if it's not passed, as seen in this line of code.

However, the bitcoin-core/secp256k1 library handles this scenario differently, opting for a deterministic approach when auxRand is not provided.

I understand this is not a bug in noble-curves, and the chosen strategy is both safe and valid. However, given these differences, I'm finding it challenging to use noble to accurately emulate the behaviour of bitcoin-core/secp256k1 when auxRand isn't provided (without resorting to forking noble-curves).

Due to the hashing, I believe it's not practically feasible to precompute an auxRand that would result in the same deterministic behaviour as in bitcoin-core/secp256k1.

I would appreciate your insights and guidance on this issue. Is there a workaround or a potential modification I can implement to align the handling of auxRand more closely with the bitcoin-core/secp256k1 approach?

Thank you for your time!

[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!

[paulmillr]

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

https://github.com/guggero/bip-schnorr/issues/32 https://github.com/bitcoin-core/secp256k1/issues/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.

[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?