Author

Topic: What is the rational for using tagged hash instead of RFC6979 in Schnorr sigs? (Read 217 times)

staff
Activity: 4284
Merit: 8808
It's simpler, it's consistent with the rest of the spec, it's faster, there is a security consideration, and if you don't like it you can do something else.

Simpler: RFC6979 is the way it is because it was designed to really be another FIPS certified RNG in disguise so that parties who were stuck with certification could potentially use it without losing their FIPS certification. This isn't a consideration for anything using secp256k1 at all. An implementation that doesn't need rfc6979 will save a fair amount of development time and a bit of code size too.

Consistent: The rest of the spec also uses the same kind of tagged hashes. The scheme in the spec is also very similar to ones used by e.g. ed25519.

Faster: RFC6979 is quite slow and turns out to take a significant amount of the total signing time.  The scheme in the bip takes two compression runs at runtime, the second of which can be done faster if you care a lot about about speed. (Not 4: it's designed so you can precompute and cache the tag part, eliminating two compression function runs).

Security consideration:  If you use ECDSA with the same key, nonce, and message as the BIP, e.g. by signing the same message with both and using RFC6979 with both, you'll leak your private key same as you would with nonce reuse across different messages in ECDSA. The BIP points this consideration out explicitly. This is due to a design flaw in RFC6979 in that it provides no domain separation, it should take the signing scheme as an input but it doesn't and without it the security goal isn't met. Signing the same message with the same key in both signature schemes is slightly contrived, but not absurd (for example there is bcash stuff that does so, and is only saved by the hair of their chinny chin chin, that the schnorr implementation they copied from us and stripped the attribution off uses a non-standard RFC6979 that takes an 'algo' input-- which we created because we were aware of this issue)... and the resulting break would likely surprise people, so it's probably better to avoid it by specifying something else.

Finally, the nonce generation scheme is non-normative. You can ultimately do what you want and you'll be compatible.  The BIP suggests several alternatives that we're likely to see in production.
legendary
Activity: 1042
Merit: 2805
Bitcoin and C♯ Enthusiast
So far in bitcoin RFC-6979 has been used (my almost all implementations) to generate the ephemeral elliptic curve key pair needed in signing operations. BIP-340 on the other hand proposed using two SHA-256 hashes called "tagged hash" in Schnorr signatures. The only benefit of this alternative that I can think of is speed as compared to RFC-6979 it computes less number of SHA-256 hashes (at least 22 SHA-2 blocks vs fixed 4 SHA-2 blocks).

Is speed the only reason? If so does it even matter as we are talking about nano-seconds here and it is for the "signing" operation not verification?
Jump to: