Update: The word “Most” in the original title of this post is incorrect — see details at end.
Cryptography is profoundly unforgiving of errors. You don’t mess with it. You don’t roll your own — you need battle-hardened algorithms that have been torture-tested by the most technically ruthless cryptographers you can find.
And you stop using old cryptographic algorithms that have known weaknesses. And you fix this sort of thing straight away.
Unless you’re in cryptocurrency, apparently.
The conclusion seems to be that at least all wallets generated by js tools inside browsers since bitcoin exists until 2011 are impacted by the Math.random weakness if applicable to the related implementations, the Math.random or RC4 (Chrome) weakness between 2011 and 2013, and RC4 weakness for Chrome users until end of 2015
And all wallets using jsbn are impacted by Math.random and RC4 until 2013 (or end 2015 for Chrome), then still by the RC4 fallback step after
What that means is that the keys will be predictable enough to crack by sheer brute-force attack of computing power. You might think you have a key long enough that it can’t be cracked before the sun goes out — but it turns out you could do it in a week.
So a lot of browser-based cryptocurrency products that still use SecureRandom() are generating keys that are open to being cracked.
Check with your product’s author or vendor — there’s a real mess to clean up here.
Like all good cryptocurrency bugs, this one isn’t new at all — here’s Greg Maxwell talking about it nearly three years ago (51:00 on):
And here’s Bitcointalk user Ditto talking about the RC4 bit in March 2013: “Patch the window.SecureRandom function, or the ArcFour PRNG inside it.” And note the response:
Why is cryptocurrency software like this.
(you know why)
- BitAddress pre-2013;
- bitcoinjs before 2014;
- current software that uses old repos they found on Github.
Also, check what your web wallet’s author or vendor says about this one.
Your subscriptions keep this site going. Sign up today!