Support for Anti-klepto protocol / Nonce exfiltration protection

[AndreasGassmann]

I just became aware of the "anti-klepto" protocol to protect against "chosen nonce" attacks.

https://github.com/ElementsProject/secp256k1-zkp/blob/ed69ea79b429beae4260917e08fe60317d38ee8d/include/secp256k1_ecdsa_s2c.h#L100-L155

It looks like in the tiny-secp256k1 library, sign takes an optional e parameter for additional entropy. I'm assuming this is for the "Nonce exfiltration protection" mentioned in https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#alternative-signing

I took a quick look at the code of this library and it looks like this is not supported. Is that something that you are planning to add in the future? We are using this library in an air-gapped environment and having this protection would be solving one of the last remaining risks of private key leakage.

[junderw]

tiny-secp256k1 uses RFC6979, which does not include any provably incorporated randomness.

The e parameter is mentioned in the second bullet point in section 3.6 of RFC6979.
https://datatracker.ietf.org/doc/html/rfc6979#section-3.6

However, there are no methods to perform a commitment exchange with the host.

---

Currently, sign uses RFC6979 and signSchnorr uses BIP340 nonce generation with optional extra data (similar to how libsecp256k1 implements it.)

Moving forward, I am going to make the ECC module more modular.

1. I have removed ECPair from bitcoinjs-lib
2. ECPair and bip32 will both take in tiny-secp256k1 as a dependency, but will be injectable. As long as the needed interface is provided, it won't matter.
3. A new tiny-secp256k1 interface-compatible library that has separate methods for verifying this protocol can be injected into ECPair/bip32

As far as possible support upstream in tiny-secp256k1, I am not against it, but it is not a priority right now.

[junderw]

The move to Rust+WASM will make it easier to implement if we have access to C libraries (using Rust FFI)