4 ms·

Well there is this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations http://www.scribd.com/doc/

by VMG 13y ago

Well there is this paper: http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations 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.

tptacek 13y ago
The bug described here isn't sufficient to generate repeated DSA k-values, even if it is still in the code†, which is unlikely. It seems more likely that the application code used SecureRandom insecurely, as described upthread. † 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.
- makomk 13y ago
  According to Mike Hearn's comment over at the Bitcoin forums[1]: > You should not assume that using OpenSSL directly is safe. On Jellybean+ the SecureRandom provider is just a shim over the OpenSSL RAND_* functions and Jellybean+ is also affected. However TLS connections are OK. > I realise there's going to be a lot of questions about what exactly is going on here, but I'm not on the Android team and can't talk on their behalf. It's up to them to document exactly how the RNG is broken. Suffice it to say, if you aren't sure if you're affected, you probably are but you are welcome to send me a private message detailing what you're doing and I'll let you know. [1] https://bitcointalk.org/index.php?topic=271486.msg2911376#msg2911376 https://bitcointalk.org/index.php?topic=271486.msg2911376#ms...
  - benmmurphy 13y ago
    that is kind of scary. i had a look over the code and the problem seems not obvious. the only issue i saw was multiple instances of SecureRandom share the same state which could cause some problems if you do [1]: x = new SecureRandom(); y = new SecureRandom(); y.setSeed(predictable); x.generateBytes(zz); and also i think the seed is thread local so you can have: x = new SecureRandom(); x.setSeed(xxx); then on another thread x.generateBytes() won't do what you think it will do. i don't think this would cause dupes because i assume apps are isolated from each other and these apps aren't calling setSeed... [1] this is assuming android people haven't patched openssl to have different behaviour and also setSeed might be safe in openssl because it uses the value to augment and not replace the state.

by VMG 13y ago

tptacek 13y ago

The bug described here isn't sufficient to generate repeated DSA k-values, even if it is still in the code†, which is unlikely. It seems more likely that the application code used SecureRandom insecurely, as described upthread. † 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.

makomk 13y ago
According to Mike Hearn's comment over at the Bitcoin forums[1]: > You should not assume that using OpenSSL directly is safe. On Jellybean+ the SecureRandom provider is just a shim over the OpenSSL RAND_* functions and Jellybean+ is also affected. However TLS connections are OK. > I realise there's going to be a lot of questions about what exactly is going on here, but I'm not on the Android team and can't talk on their behalf. It's up to them to document exactly how the RNG is broken. Suffice it to say, if you aren't sure if you're affected, you probably are but you are welcome to send me a private message detailing what you're doing and I'll let you know. [1] https://bitcointalk.org/index.php?topic=271486.msg2911376#msg2911376 https://bitcointalk.org/index.php?topic=271486.msg2911376#ms...
- benmmurphy 13y ago
  that is kind of scary. i had a look over the code and the problem seems not obvious. the only issue i saw was multiple instances of SecureRandom share the same state which could cause some problems if you do [1]: x = new SecureRandom(); y = new SecureRandom(); y.setSeed(predictable); x.generateBytes(zz); and also i think the seed is thread local so you can have: x = new SecureRandom(); x.setSeed(xxx); then on another thread x.generateBytes() won't do what you think it will do. i don't think this would cause dupes because i assume apps are isolated from each other and these apps aren't calling setSeed... [1] this is assuming android people haven't patched openssl to have different behaviour and also setSeed might be safe in openssl because it uses the value to augment and not replace the state.