 |
January 25, 2020, 03:18:29 PM
Last edit: January 25, 2020, 03:36:11 PM by gmaxwell |
|
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.
|
