To be specific, since I spent a lot of time on that bug... Older versions of Android's SecureRandom could return the same value if (a) you were manually seedin

To be specific, since I spent a lot of time on that bug... Older versions of Android's SecureRandom could return the same value if (a) you were manually seeding SecureRandom and (b) no prior crypto operations were performed on that SecureRandom instance before seeding, There was some (very) bad advice circulating on blogs which advised using this technique to generate local encryption keys from a seed, in order to obfuscate the key. This was fixed in Android 4.2 when we switched from BouncyCastle to OpenSSL as the underlying crypto provider. I don't know why you'd still be seeing this on Android 4.2, but you shouldn't be doing this anyway. SecureRandom is seeded by the system. Manually seeding it is a bad idea. (And trying to force deterministic output from is a very bad idea.) There's a blog post I wrote which goes into a bit more detail: http://android-developers.blogspot.com/2013/02/using-cryptography-to-store-credentials.html http://android-developers.blogspot.com/2013/02/using-cryptog... The linked article is a bit light on details, so I don't know if this is what they were doing or not. I doubt it though, since that would have meant they were seeding SR with the same value, and I'd like to believe the Bitcoin devs wouldn't make that mistake.