"law enforcement remains in unanimous agreement that the continued widespread availability and increasing use of strong, non-recoverable encryption products will soon nullify our effective use of court-authorized electronic surveillance." - Louis Freeh, former Director of FBI
Topic: [ANNOUNCE] Android key rotation - page 6. (Read 66313 times)
IIRC if you seed it before ever pulling a random number from it, it will only be seeded from your (quite likely weak) seed, and not the OS provided randomness. Seeding it should be unnecessary, and it makes it easy to screw yourself.
Understood. If however the "self seeding" of SecureRandom creates low entropy then it creates a master key to all cryptography used on the device including https://, SSL and not only Bitcoin.
The fact that the few Bitcoin transactions that Android Wallet user created was able to expose the weakness tells me that the flaw is serious to such and extent that I ask if it is intentional.
Edit: I mean a back door with "master key" above. Brute forcing all protocols does not require real force in absence of quality randomness.
Seed with accelerometer, gyroscope, compass, barometer, or GPS if available?
But that is exactly what the default OS implementation should be doing.Instead its seeding with a 31 bit value...
Seed PRNG with accelerometer, gyroscope, compass, barometer, or GPS if available?
http://www.gsmarena.com/glossary.php3?term=sensors
http://www.gsmarena.com/glossary.php3?term=sensors
So Google discourages seeding SecureRandom .... Why ?
Maybe the default implementation is NSA approved.
Hehe - as a guy with a "tinfoil hat" label given already, I must say that it is not an entirely unreasonable theory Maybe the default implementation is NSA approved.
IIRC if you seed it before ever pulling a random number from it, it will only be seeded from your (quite likely weak) seed, and not the OS provided randomness. Seeding it should be unnecessary, and it makes it easy to screw yourself.
So Google discourages seeding SecureRandom .... Why ?
Maybe the default implementation is NSA approved.
Maybe the default implementation is NSA approved.
I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.
Very much appreciated, thanks. And thanks to every developers who worked to push updates and instructions in a very short delay.
How are the patches working around the problem?
Are they using a different source of entropy, or are they checking that the two R-values don't collide?
In my mind, best practice would be to do both.
I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.
But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.
As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?
On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?
Any comments from the developers here? Checking the uniqueness would require storing past r values along with the private key. Any problematic consequences of this?Are they using a different source of entropy, or are they checking that the two R-values don't collide?
In my mind, best practice would be to do both.
I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.
But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.
As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?
On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?
And yes, I am surprised that there is not much buzz about the broken android PRNG in general, unrelated to Bitcoin. Does all crypto on Android rely on this broken PRNG? Who wrote this particular implementation, who let it slip by? What else has slipped by?
No need to keep track of all previews R values, since a chance of picking up the same 256 bit random number again is likely lower than a chance of the h/w failing in a away that it would broadcast such a stored R values from your history buffer.
And yes - all the other Android apps that rely on SecureRandom class are at risk.
I'm also surprised that Google does not give a shit, since it seems that they have known about this specific issue for months.
Maybe someone should sue them, to teach them a lesson.
I bet that there are plenty of (e.g. online banking) apps that are also affected.
BitcoinSpinner / Mycelium Wallet
An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.
An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.
I just removed Spinner and installed Mycelium. It reports version 0.7.0 beta, is this one safe regarding this problem?
yes it is. it also features a migration wizard if you generated a key inside Mycelium prior to 0.6.5.
How are the patches working around the problem?
Are they using a different source of entropy, or are they checking that the two R-values don't collide?
In my mind, best practice would be to do both.
I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.
But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.
As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?
On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?
Any comments from the developers here? Checking the uniqueness would require storing past r values along with the private key. Any problematic consequences of this?Are they using a different source of entropy, or are they checking that the two R-values don't collide?
In my mind, best practice would be to do both.
I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.
But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.
As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?
On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?
And yes, I am surprised that there is not much buzz about the broken android PRNG in general, unrelated to Bitcoin. Does all crypto on Android rely on this broken PRNG? Who wrote this particular implementation, who let it slip by? What else has slipped by?
It would be nice, it other App stores would also get updates. F-Droid for example doesn't yet show an update for Bitcoin Wallet.
Dia
Dia
BitcoinSpinner / Mycelium Wallet
An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.
An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.
I just removed Spinner and installed Mycelium. It reports version 0.7.0 beta, is this one safe regarding this problem?
Oh yeah, why the developers never think about it..
well, "java" in general has the idea that you do not have to think about this. as a developer you assume that it works – which in reverse is a good way to shoot yourself in the foot. in that case, the implementation of java is the problem. i don't know any details about google's modifications on the underlying linux itself, but my guess is, that it's random number source is also a good one. it's more or less just this broken link between low level to a higher levels which causes this. if the android linux-os developers are as smart as i think, they're already using all available input sensors as sources for randomness.
This is a sign of a healthy community. Bravo!
I already updated the second post after my announcement to give some credit to Jean-Pierre, though I guess most of the credit goes to the researchers who uncovered the vulnerabilities in the first place. But still, it was very useful for Jean-Pierre to inform us privately.
The Android JVM is open source. It's called Dalvik. I don't know where anyone would get the idea it's not open source from.
The Android JVM is open source. It's called Dalvik. I don't know where anyone would get the idea it's not open source from.
Oh yeah, why the developers never think about it.. using sensors as random generator that almost impossible to generate same pattern, brilliant!
Because this should be a duty of an OS, to get adventage of whatever entropy sources it has and provide the apps with an API for a secured random numbers.At least a modern OS - nobody had expected it from MS-DOS back then
yes. that's what's baffling me, too. especially given the fact, that an android device has much more sources of random information than a commodity pc. just think about gyroscope, magnetism, acceleration, ...
Oh yeah, why the developers never think about it.. using sensors as random generator that almost impossible to generate same pattern, brilliant!
It's a pretty disturbing oversight on the part of those who wrote the Android PRNG library.
yes. that's what's baffling me, too. especially given the fact, that an android device has much more sources of random information than a commodity pc. just think about gyroscope, magnetism, acceleration, ... Jump to: