I believe this has been mentioned in comment #757 (comment), but nevertheless decided to open an issue for visibility.
BIP340 https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#default-signing clearly says auxRand should always be used even if it’s all-zero. It also provides exact algorithm to calculate nonce from it.
Right now, libsecp256k1, when auxRand was not passed, uses its own nonce generation algorithm.
It would be good to make the library follow specification.
auxrand == NULL should behave identically as passing a pointer to 32 0x00 bytes. This is even tested explicitly: https://github.com/bitcoin-core/secp256k1/blob/acf5c55ae6a94e5ca847e07def40427547876101/src/modules/schnorrsig/tests_impl.h#L110-L114
I see the linked issue now. I think there is some confusion.
Both are BIP340 compliant (emphasis mine):
If randomness is not available at all at signing time, a simple counter wide enough to not repeat in practice (e.g., 64 bits or wider) and padded with null bytes to a 32 byte-array can be used, or even the constant array with 32 null bytes. Using any non-repeating value increases protection against fault injection attacks. Using unpredictable randomness additionally increases protection against other side-channel attacks, and is recommended whenever available.
Using random nonces is recommended and obviously better, but libsecp256k1 has no access to high-quality randomness; it’s up to the caller to provide it.
