Here again I will posit:<p>Secure programs should rely on /dev/urandom, to the exclusion of other CSPRNGs, and should specifically eschew userland CSPRNG engines even when they're seeded from /dev/urandom.<p>This Android bug is another in a line of bugs in userland CSPRNGs, the most famous of which was Debian's OpenSSL CSPRNG bug which gave up everyone's SSH key. CSPRNGs have bugs. When you rely on a userland CSPRNG, you're relying on two single points of failure: the userland CSPRNG and the OS's CSPRNG. Failures of <i>either</i> aren't generally survivable.<p>There are people who are smarter than me (notably 'cperciva) who disagree with me on this, but this is an idea I got from DJB's NACL design paper; it's not my own crazy idea.<p>I got to eat dinner with Dan Bernstein the other day, by the way, and it turns out NACL is pronounced "lasagna".
Since this is as good a time as any: I snidely implied that this was likely to have been due to a bug on the part of the Bitcoin community rather than a design error in the Android platform. That seemed like a reasonable guess at the time, but it was wrong, so: sorry, Bitcoin et al devs.
"Developers who use JCA for key generation, signing or random number generation should update their applications to explicitly initialize the PRNG with entropy from /dev/urandom or /dev/random."<p>Really? This is what's missing?<p>They build a whole infrastructure for crypto and forget to do <i>that</i>?
> Some SecureRandom Thoughts<p>I feel like the author of the post isn't giving this the severity that it deserves. The title makes it sound like a thought experiment, here is an example where the original title is (let's face it) shit and the editorial title here is relevant.
needless to say, android passed its fips certification with flying colors.<p>just another secure mobile OS. nothing to see here, move along.<p>did i mention that you should never store anything of actual import on a phone?
Let me get this straight. Somebody spent time to hunt down the original issue with the RNG. Followed by the time required to exploit the issue. Then focused on attacking bitcoin environment in some way. Taking a total of 55 bitcoins.<p>That seem's like a lot of work for $5000.... Some Blackhat burning 0day for giggles?<p>It's also very impressive that the BT community caught them so quickly.
/dev/urandom is usually pseudo random, so as an initialization for SHA1PRNG random number generator it is not good enough. It seems that the suggested fix is not good enough; you need a real source of entropy - which is /dev/random.<p>The problem with /dev/random is that sometimes there is not enough system entropy (depending on the available hardware sources), so reading from it can block;<p>On smartphones they might use the radio signals as a source of entropy, get some data from the radio then MD5 the stuff; couldn't they do just that ?