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.
OK, I dove a little more. The actual signing happens in org.spongycastle.crypto.signers.ECDSASigner . I haven't dug into _that_ yet.
But one thing I'm wondering is: would any setSeed on any SecureRandom instance cause a potential problem? Or just on the same instance being used for signing? In other words, do I only need to check that spongycastle -- which I presume is a fork of bouncycastle -- handles things reasonably? Or could any other messing about with SecureRandom mess it up?
the only other thing i see is the openssl securerandom code doesn't properly check the return value. it is possible for RAND_bytes to fail and for the securerandom code to not throw an exception. i think this is quite unlikely to happen. so basically:
1) reading from /dev/urandom takes more than 10ms causing an entropy error
2) a malloc fails causing the error to be saved to the fallback ERR_STATE instead of the thread local ERR_STATE
3) java sees failing code and tries to read the last error but now malloc succeeds so it reads it from its local thread ERR_STATE which succeeds or some other thread has clobbered the fallback ERR_STATE
4) java doesn't throw an exception because it sees no error
the other possibility is the openssl random state is shared between processes due to forking. i hear there is a process called the zygote that warms up the vm and forks to create apps. if it initialises openssl then it is possible child processes could get the same random state.
...I'm the packager of SpongyCastle (a task a well-trained monkey could do, I don't alter the code other than package-renaming it), and I confess some relief that the issue is with Android's in-built SecureRandom class, rather than anything in (Bouncy|Spongy)Castle.
if they are using SecureRandom backed by openssl then i think any instance is a problem. However, the 'seed' is used to augment the state and not override it. I'm not sure if it is possible or how much data would be required to get predictable output from SecureRandom by calling setSeed.
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.