Random numbers are hard to get right and it appears that faith in the word “Secure” in front of the word “Random” has tripped up developers again, this time with Bitcoin wallets on Android. Those developers have now been alerted to the fact when they are generating a random number to sign Bitcoin transactions, that random number isn’t of high enough quality and make it a lot easier to crack the signing.
These Android apps have been using the Java SecureRandom class as implemented on Android, which in turn took its code from the Apache Harmony project. As shown back in March by Chris Meyer and associates at the RSA Conference 2013, the Apache Harmony SecureRandom implementation is actually not very random at all. The less entropy there is seeding the random number generator, the more likely it is to generate the same random numbers and the more likely someone can use brute force in a reasonable time to crypto that uses those random numbers. With the Android implementation, most cases have an entropy down at 64 bits and in the worst case it goes as low as 31 bits.
But this problem does not apply to other implementations of Java’s SecureRandom: OpenJDK’s version shows “no obvious weaknesses” while GNU Classpath’s version is fine under normal load but does have some issues on heavily loaded systems. Even then, Meyer’s advice is to never use a PRNG (Pseudo Random Number Generator) in critical environments and rely on hardware entropy collectors and random number generators.
This article was imported from the original CodeScaling blog