Quote from: rocks on January 12, 2015, 10:33:12 PM

I am completely shocked that you of all people are making this claim gmaxwell. Reusing a K value is against the DSA signing algorithm's specifications. Reusing a K value is an incompetent implementation by definition. There have been multiple instances where BTC were lost because bitcoin client software reused the same K value for different signatures on the same address. If you do so you're guaranteed to find that address emptied fairly quickly, based on past instances it seems there there network monitors actively watching for this exact situation.

Maybe when you find yourself shocked you should take that as a signal that perhaps you misunderstood and should read again.

"is an incompetent implementation by definition" Exactly. And if you are using an incompetent implementation you are in extreme peril no matter how many layers of cargo-cult buzzword security theatre it's author has dressed it up in.

Insecure nonce generation isn't something that happens by chance-- not for the size of the numbers involved here, it is not some random fault, not some cosmic ray event. (Okay, sure, anything can happen, but that isn't whats has actually happened). The faults you're talking about are real but they are exclusively the result of dangerously incompetent software which would not (and in some cases did not) pass even the most straight forward review, if it were ever reviewed at all. In most (though not quite all) cases _same_ software would still be insecure, even using derandomized DSA, because it also use the same faulty procedures to generate the private keys; which have just as strong of a requirement for randomness but have no way around it.

AFAIK, I was the first or at least one of the first persons to suggest that implementations in this space probably ought to be using derandomization, e.g. http://sourceforge.net/p/bitcoin/mailman/message/31306213/ (and many times previously on IRC and directly to implementers). I went and nagged several of the early hardware wallet vendors to go change their approach, etc.

Quote

because bitcoin client software

What you should say is dangerous, incompetent software, which likely would have (or actually did) lost the users funds in several different other ways as well.

The question I was responding to, if you can find the context in this huge thread, was on the relative priority of sidechannel resistance and derandomization in Bitcoin Core. The person I was responding to thought sidechannel attack resistance was unimportant and that randomization was important (or at least more important). I responded that relatively speaking I consider sidechannel resistance more important there: the signature randomness story isn't not a disaster in Bitcoin core, and if it were the private key generation would be just as broken or worse. This isn't the same for all applications, in some applications it matters more than others. And derandomization is prudent just out of principle, so we use it for Bitcoin Core... but comparatively speaking, given the above considerations of the two I don't consider it the more important one.