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…
Android RNG Weakness Renders Bitcoin Wallets Insecure
21–30 of 105 posts
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#22Earlier quoted context omitted.
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.
This is the most likely scenario. While I don't know Java technically, .NET has a similar "vulnerability" if you use more than one RNG. It uses time to seed new values and the general rule is you use this as a singleton/static app-wide. If you don't do this, all your rng's share the exact same value. It's really awkward to stumble into as all the evidence points to the framework but when you rtfm you realize no, its…
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#23Earlier 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.
If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?
Quote:
> Apache Harmony revealed multiple weaknesses caused by implementation bugs. As a part of Android a plethora of cryptographic functions [17] rely on this PRNG. One of the bugs addresses directly the Android platform, where as the second one only targets Apache Harmony.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#24discussion 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...
That second link doesn't seem to be the current problem. The current problem is that the same random number is being returned more than once.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#25http://blog.kchandrahasa.com/blog/2013/08/09/android-4-dot-2...
However I've read somewhere that now apparently even Android 4.2 is affected which would mean there's something more? Whoever knows more, please write more technical details.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#26Does 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.
Bad advice. Use your OS's CSPRNG to get a seed, but work with your own PRNG (say, HMAC_DRBG) internally. Going to the OS every time you want a few bits is both very slow and makes it far easier for local attackers to see when you're using entropy.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#27Earlier 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.
If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?
https://bitcointalk.org/index.php?topic=271831.0
They claim the problem lies with 'a component of Android'. One of them told me that the solution was to switch from using SecureRandom to reading /dev/urandom directly. The actual source changes appear not to be public, and he wouldn't tell me details about the issue.
I tried to find the usages of SecureRandom in a couple of the apps that are supposed to be affected, but a cursory search didn't turn up much. I suspect it's inside some library that I don't know to look inside. The question, I guess, is whether all the affected apps share the same library or not -- I don't _think_ so, but if they do it would dramatically reduce my confidence that the issue lies with the Android platform, as claimed.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#28Earlier quoted context omitted.
If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?
Well there is this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-Stat... Quote: > Apache Harmony revealed multiple weaknesses caused by implementation bugs. As a part of Android a plethora of cryptographic functions [17] rely on this PRNG. One of the bugs addresses directly the Android platform, where as the second one only targets Apache Harmony.
† It's virtually certain not to be in the code, since Android's CSPRNG is based on OpenSSL now, not Harmony's built-in CSPRNG.
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#29Earlier quoted context omitted.
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…
They were explicitly seeding SecureRandom?
Re: Android RNG Weakness Renders Bitcoin Wallets Insecure
#30Earlier 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.
If the story here is that Java SecureRandom on Android is bad enough to break DSA, the headline on this story is wrong; it should be something more like "Android Doomed". Can you provide a link to something corroborating this?
https://code.google.com/p/bitcoin-wallet/source/detail?name=...
So literally they're just ripping out SecureRandom and replacing it with their own stub that reads /dev/urandom.