Topic: New Powerful Attacks On ECDSA In Bitcoin Systems (Read 2482 times)
nonsense fud
Weird and not new.
It's complaining about a combination of things; one is that BIP32 non-hardened keys effectively share the same private key (as far as someone who has the master public key is concerned). This is documented in the BIP and is the reason for the hardened keys existing. The other is that ECDSA implementations with broken RNGs can compromise users private keys. This is also well known.
Community concern about that (see my own post http://permalink.gmane.org/gmane.comp.bitcoin.devel/2734 and https://bitcointalksearch.org/topic/deterministic-usage-of-dsa-and-ecdsa-digital-signature-algorithms-rfc-6979-285142) is why limited entropy devices like trezor use derandomization already. Incidents like bc.i's compromise in the past are largely unrelated (broken JS code that could just fail to use randomization at all), or just toy implementations which which were seemingly intentionally insecure.
In the case of Bitcoin Core the system has a strong CSPRNG seeded by strong system randomness and other inputs. There have never been any incidents there, and if there were any they would also compromise the ordinary private keys regardless of derandomization of the ECDSA. Support for derandomization exists only in pre-release openssl (and has for more than a year), though the new library Pieter wrote has support for it (and resolves a number of other issues with OpenSSL). But since the private keys depend on the same randomness, and the randomness is strong everywhere Bitcoin core is supported, I haven't considered it a major priority.
Many of the author's other complaints are just strange, e.g. arguing Bitcoin "lacks a cryptographer to tell us elementary truths about which elliptic curves are mainstream (P-256 and not many more!) and which ones are dodgy, with a collapse of bitcoin looming if bitcoin cryptography is broken some day", which is just weird as there are a great many cryptographers working on Bitcoin (including ones carrying PHDs), so I can only assume what thats really complaining is that no one is paying him, in particular, to give us bad advice like using curves with suspicious fake-random unexplainable NSA sourced parameters. Also I find it weird that after saying that he complains about widely deployed standards compliant randomized DSA to the favor of more recently developed standard-violating derandomized DSA. (As seen in the posts, I'm also in favor of using derandomized DSA, it's just odd to fault Bitcoin for being non-mainstream in not using NIST curves, while at the same time faulting it for not violating the DSA standards).
I see that his latest writing has toned down the ransom-note-esq random modulation into ALLCAPS, but it still succeeds in being chuckle worthy with gems such as "In August 2013 we found on the Internet another file posted anonymously by a certain Greg, which contained 131 bad randoms".
It's complaining about a combination of things; one is that BIP32 non-hardened keys effectively share the same private key (as far as someone who has the master public key is concerned). This is documented in the BIP and is the reason for the hardened keys existing. The other is that ECDSA implementations with broken RNGs can compromise users private keys. This is also well known.
Community concern about that (see my own post http://permalink.gmane.org/gmane.comp.bitcoin.devel/2734 and https://bitcointalksearch.org/topic/deterministic-usage-of-dsa-and-ecdsa-digital-signature-algorithms-rfc-6979-285142) is why limited entropy devices like trezor use derandomization already. Incidents like bc.i's compromise in the past are largely unrelated (broken JS code that could just fail to use randomization at all), or just toy implementations which which were seemingly intentionally insecure.
In the case of Bitcoin Core the system has a strong CSPRNG seeded by strong system randomness and other inputs. There have never been any incidents there, and if there were any they would also compromise the ordinary private keys regardless of derandomization of the ECDSA. Support for derandomization exists only in pre-release openssl (and has for more than a year), though the new library Pieter wrote has support for it (and resolves a number of other issues with OpenSSL). But since the private keys depend on the same randomness, and the randomness is strong everywhere Bitcoin core is supported, I haven't considered it a major priority.
Many of the author's other complaints are just strange, e.g. arguing Bitcoin "lacks a cryptographer to tell us elementary truths about which elliptic curves are mainstream (P-256 and not many more!) and which ones are dodgy, with a collapse of bitcoin looming if bitcoin cryptography is broken some day", which is just weird as there are a great many cryptographers working on Bitcoin (including ones carrying PHDs), so I can only assume what thats really complaining is that no one is paying him, in particular, to give us bad advice like using curves with suspicious fake-random unexplainable NSA sourced parameters. Also I find it weird that after saying that he complains about widely deployed standards compliant randomized DSA to the favor of more recently developed standard-violating derandomized DSA. (As seen in the posts, I'm also in favor of using derandomized DSA, it's just odd to fault Bitcoin for being non-mainstream in not using NIST curves, while at the same time faulting it for not violating the DSA standards).
I see that his latest writing has toned down the ransom-note-esq random modulation into ALLCAPS, but it still succeeds in being chuckle worthy with gems such as "In August 2013 we found on the Internet another file posted anonymously by a certain Greg, which contained 131 bad randoms".
The so called 'powerful new attack' happens if you give your master public key AND you use a scrappy prng.
No new research at all. just fud.
No new research at all. just fud.
All these "vulnerabilities" are all things that are known and accepted under the umbrella of safe security practices.
ie.
1. Bad RNG for signing
2. Bad RNG for private key generation
3. releasing Master Public Key along with one of the Private keys derived from its tree
These are all known no-nos for crypto.
The only thing that is slightly on the ball is that thanks to this guy a lot of script kiddies now are aware of vulnerabilities and have a one button press tool to discover reused r values, so the speed at which your bitcoins will be stolen when you perform one of the top 3 bad security practices is faster...
But this is not anything newly discovered.
Just like Gox claiming transaction malleability was some new vulnerability, these people run around saying "omg I found heartbleed bug and now I found a brand new vulnerability in Bitcoin!" and normal people don't know any better and panic.
Crypto relies on random numbers. This is an unavoidable fact of crypto, and will be a weakness for as long as crypto exists.
Deterministic signatures are fine and dandy, but useless if your private key was generated on crappy RNG.
+1ie.
1. Bad RNG for signing
2. Bad RNG for private key generation
3. releasing Master Public Key along with one of the Private keys derived from its tree
These are all known no-nos for crypto.
The only thing that is slightly on the ball is that thanks to this guy a lot of script kiddies now are aware of vulnerabilities and have a one button press tool to discover reused r values, so the speed at which your bitcoins will be stolen when you perform one of the top 3 bad security practices is faster...
But this is not anything newly discovered.
Just like Gox claiming transaction malleability was some new vulnerability, these people run around saying "omg I found heartbleed bug and now I found a brand new vulnerability in Bitcoin!" and normal people don't know any better and panic.
Crypto relies on random numbers. This is an unavoidable fact of crypto, and will be a weakness for as long as crypto exists.
Deterministic signatures are fine and dandy, but useless if your private key was generated on crappy RNG.
I'm certainly not a crypto expert, but yeah, random numbers are paramount. Also, that paper had some of the ugliest diagrams I have ever seen.
All these "vulnerabilities" are all things that are known and accepted under the umbrella of safe security practices.
ie.
1. Bad RNG for signing
2. Bad RNG for private key generation
3. releasing Master Public Key along with one of the Private keys derived from its tree
These are all known no-nos for crypto.
The only thing that is slightly on the ball is that thanks to this guy a lot of script kiddies now are aware of vulnerabilities and have a one button press tool to discover reused r values, so the speed at which your bitcoins will be stolen when you perform one of the top 3 bad security practices is faster...
But this is not anything newly discovered.
Just like Gox claiming transaction malleability was some new vulnerability, these people run around saying "omg I found heartbleed bug and now I found a brand new vulnerability in Bitcoin!" and normal people don't know any better and panic.
Crypto relies on random numbers. This is an unavoidable fact of crypto, and will be a weakness for as long as crypto exists.
Deterministic signatures are fine and dandy, but useless if your private key was generated on crappy RNG.
ie.
1. Bad RNG for signing
2. Bad RNG for private key generation
3. releasing Master Public Key along with one of the Private keys derived from its tree
These are all known no-nos for crypto.
The only thing that is slightly on the ball is that thanks to this guy a lot of script kiddies now are aware of vulnerabilities and have a one button press tool to discover reused r values, so the speed at which your bitcoins will be stolen when you perform one of the top 3 bad security practices is faster...
But this is not anything newly discovered.
Just like Gox claiming transaction malleability was some new vulnerability, these people run around saying "omg I found heartbleed bug and now I found a brand new vulnerability in Bitcoin!" and normal people don't know any better and panic.
Crypto relies on random numbers. This is an unavoidable fact of crypto, and will be a weakness for as long as crypto exists.
Deterministic signatures are fine and dandy, but useless if your private key was generated on crappy RNG.
Jump to: