BIP 340 and RFC 6979 and variable length messages

[mleku]

The BIP-340 support is not complete in btcec. It does not accept variable length messages, and it does not contain the extra 4 tests added to it that test this capability.

The following code needs to be commented out, as this is no longer correct:

https://github.com/mleku/ec/blob/master/schnorr/signature.go#L129

The extra vectors to completely conform to BIP-340:

https://github.com/mleku/ec/blob/master/schnorr/signature_test.go#L151

I want to draw extra attention to the fact that RFC6979 must not be enabled for the tests involving the non-32 byte long messages, as the result of this will be a forever loop if only the 32 byte length guard is removed but the RFC6979 nonce is added to the options.

Going over the test vectors it is clear that in fact, normally RFC6979 should not be used with Bitcoin (and Nostr) Schnorr signatures at all, since the security flaw this RFC aims to eliminate is handled by the BIP 340 tagged nonces.

I am not sure exactly what use cases there are in this nonstandard signature scheme that is BIP-340, but with the above changes, btcec will allow them to be implemented in Go.

[Roasbeef]

It does not accept variable length messages, and it does not contain the extra 4 tests added to it that test this capability.

Hi correct that this isn't fully implemented. We never implemented as:

1. Typically in Bitcoin situations, we're always signing a 32-byte sighash.
2. No opcodes today in Bitcoin actually use the variable length message signing.

Going over the test vectors it is clear that in fact, normally RFC6979 should not be used with Bitcoin (and Nostr) Schnorr signatures at all, since the security flaw this RFC aims to eliminate is handled by the BIP 340 tagged nonces.

I'm not sure what you mean by this, see the section on "alternative signing": https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki#user-content-Alternative_Signing

This can be most reliably accomplished by not reusing the same private key across different signing schemes. For example, if the rand value was computed as per RFC6979 and the same secret key is used in deterministic ECDSA with RFC6979, the signatures can leak the secret key through nonce reuse.

We counteract this by using a distinct RFC6979 tag for the ECDSA and Schnorr signatures. IMO RFC6979 is still an improvement to the ergonomics of the scheme, as it does away with the requirement to generate secure randomness for each signature.

[mleku]

I'm completely unable to respond to this. I won't bother in future, my experience with your dev group is pretty consistent.