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 cross-referenced this on Aug 7, 2020 from issue Add schnorrsig module which implements BIP-340 compliant signatures by jonasnick
8. 
   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

9. real-or-random renamed this:
   Passing data to default nonce function
   Nonce functions
   on Sep 23, 2020
10. real-or-random cross-referenced this on Sep 23, 2020 from issue memcmp may be miscompiled by GCC by real-or-random
11. real-or-random cross-referenced this on Jan 16, 2022 from issue Modulo-reduce msg32 inside RFC6979 nonce fn to match spec. Fixes #1063 by paulmillr
12. real-or-random cross-referenced this on Sep 14, 2022 from issue Protecting ecmult_gen against side-channel attacks: the big picture by real-or-random
13. paulmillr cross-referenced this on Jun 28, 2023 from issue Schnorr is not compatible with BIP340 by paulmillr

Contributors
real-or-random jonasnick elichai

Milestone
stable release (1.0.0-rc.1)