randstorm vulnerability: bitaddress.org named. about bitaddress.org

[pointbiz]

TL;DR if you made your private key with bitaddress v2.7 or newer than nothing to worry about.

Issue #35 gives an overview of the quality of the entropy in the random number generator and what fixes were done to address the issue inherited from BitcoinJS.

There are no known randomness issues after commit 008c727 on Dec 15, 2013 where the browser RNG was XOR with the ArcFour PRNG. Additional improvements were added in commit 3d135f7 on Jan 18 2014. The versions above and newer have the necessary 256-bit of entropy minimum.

Regarding to versions before Dec 15 2013 it's not clear that everyone had a minimum of 90-bit entropy (to feel safe). Math.random and the timestamp and the screen size were definitely used for every key generation, I believe this is roughly the 48-bit entropy vulnerability that the disclosure mentions. The code from Nov 6 2011 was written to add an additional minimum 60-bits of entropy by seeding the mouse position (and timestamp) an additional 50+ times (totaling 90+ bit entropy); this code may have been ineffective if the mouse was not moved before a too short timeout was reached (forcedGenerate function in the code). Leaving the key with less than 90-bit entropy.

The versions of bitaddress from Nov 6 2011 to 15 Dec 2013 (v2.6 and older) are potentially at risk from the randstorm disclosure (especially if you were slow to move the mouse or didn't move the mouse at all). The disclosure team has described the attack in further detail than has been previously explicitly described. This increases the risk that keys with weak randomness will be brute forced by attackers.

This issue is not new and was fixed 10 years ago for bitaddress.

Edited for accuracy.

[pointbiz]

It should be noted that there are no heroes. We have to earn this. Only time hardens code. That's why BitAddress is effectively ossified.

math.Random was left weak by experts working for Javascript language vendors (numerous times).
window.crypto.random was improperly deprecated by browser developers.
window.crypto.getRandomValues has had multiple CVE disclosures.
The secure random number generator in Java used in Android was also broken in the past (see CVE).

This recent disclosure team has specifically mentioned BitAddress as an example of demonstrating good entropy.

I don't subscribe to the school of thought that non-type-safe languages (Javascript) should not build cryptographic libraries. The above broken random number generators mentioned were all coded in type-safe languages.

We must understand the adversary. BitAddress takes the browser's operating system hardware entropy and XORs it with the human mouse movement entropy (or keystrokes) this means any intentional vulnerability in the operating system or browser will not compromise the strength of your key because there's at least 256-bit of human entropy to protect you.

Most other wallets on the market are just using the random number generator shipped by the NSA or Google or MS or Apple all who are under non-disclosure agreements to weaken cryptography (as history has shown).

The only thing better is to use dice rolls. For newbies using Bluewallet and a 6-sided die is appropriate. You can also use a 6-sided die with BitAddress (the first example of this technique).

If you want the extremely paranoid technique use a 16-sided die (1 to 9 is 1 to 9, 10 is A, 11 is B, 12 is C, 13 is D, 14 is E, 15 is F, 16 is 0) and roll it 64 times to generate your key directly in hexadecimal and paste it into an offline version of BitAddress Wallet Details tab to get your compressed private key and compressed address. This way you bypass any conversions from BigInteger to private key and you just convert directly from the hex private key to the wif private key. This means the same string you randomly created with die rolls is your key and you are not trusting the software to convert your entropy into a key. The entropy is your key in this technique.

[vgdss]

These are good questions, I would also like a position from a developer.