On 25/08/13 23:45 PM, Marco Pozzato wrote:
Hi all,
I'm CTO at PrivateWave, developing solutions for secure telephony.
Recently, android SecureRandom PRNG proved to be seriously flawed
(http://android-developers.blogspot.it/2013/08/some-securerandom-thoughts.html)
because, by default, it is not properly initialized with "good" entropy.
The weakness is very critical, because initial state is practically
affected only by process ID: when an application starts with the same
PID, it generates the very same sequence of pseudo-random numbers.
Ouch!
Many bitcoin applications suffered this issue and some bucks has been lost.
Are you aware of some lists of flawed applications, not only related to
bitcoin, but also in other cryptography and security domain?
In some pre-release sense, my app was effected in that I'd done the work
to replace dependency on SecureRandom by centralising the source of it
into one file, but I hadn't actually given it a new SR as yet. A timely
reminder, as we're about to require it.
(An earlier bug was the BigInteger failure in 2.2 Android, which caused
certain public key operations to fail. That was much more debilitating
because it wasn't easy to isolate, until I found the comments from
Bitcoin developers that hinted at the actual bug.)
Our product, PrivateGSM, is not affected and I want to express here my
thanks to Philip Zimmermann, who I had the pleasure and the honor to
work with some years ago, when we was advisor in PrivateWave's
scientific board and we jointly worked on the first mobile ZRTP client
and designed a bitstream variant of ZRTP protocol, so called ZRTP/S.
He insisted a lot on initializing PRNG with good entropy, such as noise
from microphone, not trusting OS. Now I can fully and better appreciate
that hint: thanks Phil.
Absolutely. Phil cares.
I'd like to share with you the results of some tests we run on android
devices to assert the weakness of SecureRandom, without proper
initialization.
Flawed: after a few hundreds runs, PIDs start duplicating and the very
same sequence is generated:
Hmm... that's not even a rainbow table, more like fifty shades of grey...
* Android Simulator 4.2
* Galaxy Nexus 4.3
* Samsung Galaxy S4 4.2.2
* HTC One X 4.1.1
* Motorola Razr 4.1.2
Apparently not flawed: despite PIDs duplicates, random does not repeats.
* Samsung Galaxy Note II 4.1.2
* Samsung Galaxy S3 4.1.2
* Samsung Galaxy SII 4.1.2
* Motorola Defy Cyanogen 10.1
So, it's all over the map. A problem with Android development is that
bugs of this nature don't typically ever get fixed, we have to wait
until the entire stock of phones is rolled over.
Then, we decided to continue our tests to assert the quality of
SecureRandom: DieHard test proved a good quality of sequence generated
with SecureRandom...
...as long as you you start in the right way :-)
Thanks for the report, it provides some valuable clarification.
iang
_______________________________________________
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
