Nonce functions #757

1. 
   real-or-random commented at 3:07 PM on June 10, 2020: contributor

   At the moment you can call secp256k1_ecdsa_sign with parameters noncefp == NULL and noncedata != NULL. This basically says "give me whatever function you think you should be the default but feed it this data", which is not really meaningful. This will be relevant if we want to change the default in the future, which is not too unlikely I think.

   I see two ways:

   • Either we simply disallow this call (ARG_CHECK), or
   • we provide the guarantee that any default function will accept and use some (fixed-length) string of additional entropy.

   After the investigation into synthetic nonces in BIP340, I slightly prefer the second option because I don't want to discourage people from adding entropy while leaving the choice of the function to the library. What do you think?

2. real-or-random added this to the milestone initial release (1.0.0-rc.1) on Jun 10, 2020
3. 
   jonasnick commented at 8:41 AM on June 15, 2020: contributor

   I don't want to discourage people from adding entropy while leaving the choice of the function to the library.

   I'd be surprised if people don't make use of this already and while it's not explicitly documented I don't think we would ever switch the default to a function that doesn't add noncedata entropy.

4. 
   elichai commented at 8:53 AM on June 15, 2020: contributor

   I'd be surprised if people don't make use of this already

   In rust-secp we don't, if this will be documented I'll add a feature that will seed randomness into the ecdsa_sign nonce function,

   bitcoin core actually uses that entropy as counter and does not seed it (https://github.com/bitcoin/bitcoin/blob/195822f1e05e2f36002c906667d4c639663f23b5/src/key.cpp#L215 (I might open a PR to make the counter start at a random point))

5. 
   real-or-random commented at 9:02 AM on June 15, 2020: contributor

   @elichai but both rust-secp and core specify secp256k1_nonce_function_rfc6979 instead of null.

   bitcoin core actually uses that entropy as counter and does not seed it (https://github.com/bitcoin/bitcoin/blob/195822f1e05e2f36002c906667d4c639663f23b5/src/key.cpp#L215 (I might open a PR to make the counter start at a random point))

   If we believe in the results of BIP340, we may even want to have randomness there in every call and not only at the start. https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#default-signing

   We should also propose to change the derivation function to the one used in BIP340, but that's a larger thing. @jonasnick Is this something we could change in the Schnorr PR? Maybe introduce the nonce derivation function in a separate PR and make it available for ECDSA already now?

6. 
   jonasnick commented at 8:26 PM on June 15, 2020: contributor

   The BIP340 nonce function as implemented in #558 is not a secp256k1_nonce_function because it takes the xonly_pubkey as an additional argument so we'd need some kind of wrapper. But would be easy to open a PR with a copy of the schnorrsig PR nonce function and rebase the schnorrsig PR on top if that gets merged.

7. 
   real-or-random commented at 8:47 AM on September 23, 2020: contributor

   So we he had to introduce a new API for Schnorr nonce functions ("hardened") in order to support hashing the public key. Can we works towards unifying the two types? Maybe with an optional public key argument, and if it's NULL, we hash a constant string? edit: This could help us deprecating the current nonce function and switch the default nonce function for ECDSA to the BIP340 function.

   Here's another issue: Our BIP340 implementation implements an algo16 argument for the nonce function. I think the API is somewhat unusual and not really ergonomic. We read up to 16 bytes, ignoring trailing zero bytes. So this is neither an ordinary 16 byte array, nor is it an zero-terminated ordinary string. We tend to avoid variable-length strings but maybe in this case expecting a byte array and a length will be better?

   See https://github.com/bitcoin-core/secp256k1/blob/d7838ba6a6ac77cec173080f20efcd0e311ebfaa/src/modules/schnorrsig/main_impl.h#L68-L80

8. real-or-random renamed this:
   Passing data to default nonce function
   Nonce functions
   on Sep 23, 2020
9. 
   sipa commented at 9:37 AM on May 9, 2026: contributor

   I think this could be considered part of a better API design opportunity if we were to add a dedicated ECDSA module.

10. 
    sipa commented at 9:43 AM on May 9, 2026: contributor

    Also, I think we should just promise that the default will forever remain secp256k1_nonce_function_rfc6979, for example because we have users that have test vectors of the form "signing this message with this key, is this signature".

11. 
    real-or-random commented at 2:15 PM on May 13, 2026: contributor

    Let's track this in #974.

12. real-or-random closed this on May 13, 2026

    ---

Contributors

real-or-randomjonasnickelichaisipa

Milestone
stable release (1.0.0-rc.1)