I reached out to Colin Percival (
who wrote scrypt, for example) for his thoughts/comments on RFC 6979. Here's what he had to say (with his permission):
::sigh:: If adding the secret to the input were problematic the entire signing function would very likely be insecure: Computing a collision is easier than recovering an unknown pre-image, doubly so because the next thing you do is multiply K by G to get R, which both reduces the space of the output, and makes K unrecoverable from unless you can solve a discrete log problem.
The cost of this is that you produce a device whos correct behavior is not measurable. It could have backdoors inserted in several forms which would be very difficult to discover, or it could have flawed operation.
e.g. if it gets hot there are random bitflips in the multiply used to derive R from K, because the twist of secp256k1 is a smooth field where solving the DLP is relatively easy a single bit-flip in the multiply can result in a R value from which K can be recovered in about 2^51 work.
[Edit: Actually this is incorrect secp256k1 is twist secure, the error there resulted from an apparently transcription error copying down the order of the twist for factoring. Of course the potential for backdoors in DSA nonce generation are universal and apply to all curves, and to edDSA as well]
Essentially I view this as increasing weakness to these specific but "kind of boring" threats which I can articulate and even show you demonstrations of (e.g. the backdoored signers) in favor or speculatively increasing security against vague cryptographic boogymen, which— if they exist at all— will probably kill us all regardless (by allowing collisions on the data being signed, and thus allowing signature rebinding).
Two stages, depending on user paranoia:
1) Update the device before using it, with known good firmware (cryptographically signed + deterministic compilation). [Does not rule out rootkit]
2) Open the device, visually verify hardware, and use JTAG/SWD to manually wipe and flash. [Rules out rootkit, FPGA masquerade, etc]
This will mitigate all reasonable attacks. The only one left would a malicious custom ASIC pretending to be the MCU. But if your attacker is willing to spend millions of dollars ... hell, you must be doing something right in your life.
So this doesn't really quite reflect the "defense model" I'm going for. Realistically— whos going to go and do those things? Even of those people with a million dollars to protect? Very few.
But not zero, a few geeks are reasonably likely to go splunking around— and I'd think that really any one attempting to be a vendor in this space should even set aside some budget to pay for third party auditing to make _sure_ some external eyes dig in deep.
What I think what would be beneficial for the Bitcoin-using economy is if these few rare instances of crazy, curious, or otherwise motivated adventure seekers somehow protected all of us from badness. This is what happens with open code: When I review code thoroughly, I'm not just protecting myself: I'm protecting everyone I can communicate with.
The problem with (2) there is that I can't tell if the device was unfaithful to begin with. So if I'm the guy who doesn't trust my device the result is that I get a safe device, but I don't get the ability to sound an alarm to warn anyone else. In particular, if the device is deterministic, someone who goes in with the logic analyzers can certify the device and document the behavior, then other people can randomly check that their devices measure the documented behavior with far less work.
A compromise in the middle if the device has a display: when signing, show the extra "bonus" randomness on the display. The behavior could still then be completely deterministic (assuming you capture the bonus randomness).. but since the protocol should still be secure against anything by cryptographic boogymen even if the "bonus randomness" is just a constant it should be harmless to display it, you could even send it over USB to the host. Unless you're worried about boogmen who can invert sha256 and own a camcorder (or, in the latter, and who've hacked your computer).
I hope you don't think I'm ranting at you too much. My replies here are all in the spirit of talking through building the best and most practically secure systems possible— a goal I think we all share.
