11–20 of 105 posts
discussion on bitcointalk.org: https://bitcointalk.org/index.php?topic=271486.0 blogpost about weakness in java.security.SecureRandom: http://armoredbarista.blogspot.com.au/2013/03/randomly-faile...
this could be a big blow to Bitcoin adoption... Is this a part of Android that can't be touched by anyone but Gooogle? Or is it a piece of software that can be improved upon by open source devs?
Iä! Digital Signature Algorithm! The Black Goat of the Woods with a Thousand Crypto Bugs! I don't know the Bitcoin software involved at all, but I can sketch out an attack that might shed some light on it, and, more importantly, instill an appropriate fear of DSA into you: To generate a DSA key, you come up with primes p and q and a generator g, which process is a paralytic non-Euclidian brain injury I will not attem…
Does it concerns only Bitcoin wallets? What about other encryption under Android - like files, etc?
This is a Bitcoin software implementation bug, and an illustration of why you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG.
Earlier quoted context omitted.
I don't think it's a very big deal. For the most part, people who use bitcoin now are still very early adopters and are techies. Also, IMHO, it would be idiotic to have significant bitcoin value stored on an Android phone, and very few people (if anyone) would do that.
People are saying it's a problem with Android's SecureRandom implementation. That would be a pretty big problem if it returns repeated random numbers. But it seems strange that such a large obvious problem would make it into Android. The other explanation is that Android bitcoin developers are all implementing it incorrectly and either don't realize it or are trying to push the blame somewhere else.
Earlier quoted context omitted.
This is a Bitcoin software implementation bug, and an illustration of why you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG.
As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.
Can you provide a link to something corroborating this?
Earlier quoted context omitted.
I don't think it's a very big deal. For the most part, people who use bitcoin now are still very early adopters and are techies. Also, IMHO, it would be idiotic to have significant bitcoin value stored on an Android phone, and very few people (if anyone) would do that.
People are saying it's a problem with Android's SecureRandom implementation. That would be a pretty big problem if it returns repeated random numbers. But it seems strange that such a large obvious problem would make it into Android. The other explanation is that Android bitcoin developers are all implementing it incorrectly and either don't realize it or are trying to push the blame somewhere else.
It's really awkward to stumble into as all the evidence points to the framework but when you rtfm you realize no, its really pebkac.
I'm not saying this can't be a vulnerability in the framework, just this is the most likely scenario.
Earlier quoted context omitted.
This is a Bitcoin software implementation bug, and an illustration of why you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG.
As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.
One easy way to shoot yourself in the foot with SecureRandom is to use seed values from a source with low entropy.
http://developer.android.com/reference/java/security/SecureR...
If one were to copy/paste the sort of code samples which show up when one Googles for [Android SecureRandom], one would more than likely call setSeed, possibly in such a fashion as to duplicate seeds and, predictably, make the output of the random number generator deterministic.
I will leave it to one's individual judgement as to whether "It is unlikely a serious developer would copy/paste in crypto code into a project that has real money on the line" is descriptive of the prevalent standard of care in engineering in the Bitcoin community.
Earlier quoted context omitted.
As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.
As tptacek has mentioned many, many times, SecureRandom is one of those things which is very secure if you understand exactly what it is doing and do not shoot yourself in the foot. One easy way to shoot yourself in the foot with SecureRandom is to use seed values from a source with low entropy. http://developer.android.com/reference/java/security/SecureR... If one were to copy/paste the sort of code samples which sh…
Earlier quoted context omitted.
As far as I know that is NOT correct. The wallets in question were all -- to my knowledge -- using the Android platform-provided Java SecureRandom generator.
As tptacek has mentioned many, many times, SecureRandom is one of those things which is very secure if you understand exactly what it is doing and do not shoot yourself in the foot. One easy way to shoot yourself in the foot with SecureRandom is to use seed values from a source with low entropy. http://developer.android.com/reference/java/security/SecureR... If one were to copy/paste the sort of code samples which sh…