Hacker News Reader

Comment by Buge | Hacker News Reader

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.

View on HN

It 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.

Extremely 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.

This 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.

A secure random number generator wouldn't seed based on time in the first place, though.

Even Java's non-secure RNG doesn't do that (anymore):

public Random() { this(++seedUniquifier + System.nanoTime()); }

Reply on news.ycombinator.com