4 ms·
People are saying it's a problem with Android's SecureRandom implementation. That would be a pretty big problem if it returns repeated random numbers. But it s
by Buge 13y ago
People are saying it's a problem with Android's SecureRandom implementation. That would be a pretty big problem if it returns repeated random numbers.
But it seems strange that such a large obvious problem would make it into Android. The other explanation is that Android bitcoin developers are all implementing it incorrectly and either don't realize it or are trying to push the blame somewhere else.
- jadeddrag 13y agoIt is very likely that the bitcoin community would be the first to stumble onto a crypto bug in SecureRandom. Google should thank that community for their discovery.
- makomk 13y agoExtremely likely, in this case. It looks like the way it was discovered is that various people have set up bots to take Bitcoins from transactions with repeated r values, and they took coins from Android Bitcoin clients that on paper were doing everything right.
- w0rd-driven 13y agoThis is the most likely scenario. While I don't know Java technically, .NET has a similar "vulnerability" if you use more than one RNG. It uses time to seed new values and the general rule is you use this as a singleton/static app-wide. If you don't do this, all your rng's share the exact same value. It's really awkward to stumble into as all the evidence points to the framework but when you rtfm you realize no, its really pebkac. I'm not saying this can't be a vulnerability in the framework, just this is the most likely scenario.
- Dylan16807 13y agoA secure random number generator wouldn't seed based on time in the first place, though.
- brazzy 13y agoEven Java's non-secure RNG doesn't do that (anymore): public Random() { this(++seedUniquifier + System.nanoTime()); }