An interesting point here is that the mistake which led to the most recent problem may have been (in fact probably was) an attempt to work around the previous problem.
IE, they probably overrode SecureRandom and were getting numbers from random.org to mix with the output of the parent class, specifically BECAUSE of the earlier issue with SecureRandom.
An interesting point here is that the mistake which led to the most recent problem may have been (in fact probably was) an attempt to work around the previous problem.
IE, they probably overrode SecureRandom and were getting numbers from random.org to mix with the output of the parent class, specifically BECAUSE of the earlier issue with SecureRandom.
From what I've seen of this, the most crucial problem was not checking for success (ie status 200) on the HTTP response. While in my opinion, it seems a little pointless to use an http connection to an external service to get entropy on a device that has a gyroscope/radio and several other natural noise sources (in addition to SecurRandom), it seems that if the had simply validated the response from random.org properly they would have caught this before it caused real problems.
I never said that it was the best method for working around the problem, nor did I say that it was implemented competently.
What I think it was, was a "quick fix" that they could get out the door in 24 hours when the problem with the Android RNG was discovered, which they probably planned to get back to and fix "for real" with error checking and probably an onboard source of bits and so on....
But such plans are hardly ever fulfilled. Some security-ignorant beancounter goes, "We have a workaround? Cool, now we need to work on this other thing instead." And they never get back to it.
From reading another article, I got the impression that they did in fact try to get entropy from two sources (the phone itself and Random.org). It's only that in some cases, the app failed to use both sources and only used Random.org for whatever reason and that was the cause of the problem.
I'll see if I can dig up the article somewhere...
EDIT: Found it:
Additionally, in certain cases, the pseudorandom number generator in Blockchain for Android failed to access random data that was supposed to be mixed into the random bits downloaded from random.org. Instead of returning an error, the app simply used the 256-bit number provided by random.org as the sole input for generating private keys. That meant the random.org website was the sole supplier of entropy used in the generation process.
Link:
http://arstechnica.com/security/2015/05/crypto-flaws-in-blockchain-android-app-sent-bitcoins-to-the-wrong-address/So not only did they fail to catch the fact that Random.org was returning an error message, but they also failed to catch the fact that they weren't using two sources of entropy. Had just one of those issues been fixed, it's likely this problem wouldn't have existed at all.
