Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Android RNG Weakness Renders Bitcoin Wallets Insecure

bitcoin.org

Post reply on HN
Print view View original

51–60 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#51

Post by fixxer »

fixxer wrote: post #46
tptacek wrote: post #6

Iä! Digital Signature Algorithm! The Black Goat of the Woods with a Thousand Crypto Bugs! I don't know the Bitcoin software involved at all, but I can sketch out an attack that might shed some light on it, and, more importantly, instill an appropriate fear of DSA into you: To generate a DSA key, you come up with primes p and q and a generator g, which process is a paralytic non-Euclidian brain injury I will not attem…

On a side note, what are the current stats for the Matasano crypto challenge? How many have finished all 6?

On a side note to my side, how many are psyched about Breaking Bad tonight?!

(seriously, downvoted for asking about stats on cryptopals? it is relevant -- #6 has two DSA questions!)

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#52

Post by marshray »

tptacek wrote: post #47
marshray wrote: post #43

Earlier quoted context omitted.

The Debian OpenSSL bug was a result of Debian patching OpenSSL's RNG to make it utterly broken. Unless you're going to claim Debian couldn't have patched an equivalent bug into the kernel, you can't generalize this as support for the claim that kernel RNGs are inherently superior to library RNGs.

I'm saying the error was unforced because the effort the OpenSSL CSPRNG went through was duplicative.

So your position is that Debian didn't go far enough?

They should have disabled OpenSSL's CSPRNG entirely and redirected its internal calls to perform IO operations on /dev/[u]random?

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#53

Post by runeks »

DanBC wrote: post #7

I always wonder if some people are watching announcements to try to grab unsecured bitcoins before other people implement fixes?

The reason it was discovered in the first place was that coins were suddenly disappearing from wallets. So it's very likely that someone has already set up a bot that scans new transactions from the same address for repeating r values.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#54

Post by tedunangst »

tptacek wrote: post #37
cperciva wrote: post #26

Earlier quoted context omitted.

you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG Bad advice. Use your OS's CSPRNG to get a seed, but work with your own PRNG (say, HMAC_DRBG) internally. Going to the OS every time you want a few bits is both very slow and makes it far easier for local attackers to see when you're using entropy.

Strongest possible disagree. For instance, the Debian OpenSSL bug was an entirely unforced error stemming from applications that chose to use Debian OpenSSL's terrible CSPRNG on top of the OS's CSPRNG. The local attacker scenario you're talking about is a theoretical risk when there are attackers running code in the same OS as your CSPRNG; a far more likely concrete flaw is, for instance, a SecureRandom implementatio…

This seems the complete opposite of your usual advice to use a library. You want every app developer to memorize the intricacies of which of random or urandom or srandom they should use on which OS and whether they need to worry about blocking or short reads and whether the entropy returned is good, or really good, or just good enough? You don't think people are going to dick that up? I'd trust the OpenSSL devs to figure this mess out before John Q. Random developer. Any day.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#56

Post by benmmurphy »

makomk wrote: post #45
tptacek wrote: post #28

Earlier quoted context omitted.

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.

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 th…

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.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#57

Post by benmmurphy »

gwillen wrote: post #36
glurgh wrote: post #32

Earlier quoted context omitted.

That's the lib, if you're bored enough to keep diving https://code.google.com/p/bitcoinj/

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 reasona…

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.

http://www.openssl.org/docs/crypto/RAND_add.html

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#59

Post by makomk »

jadeddrag wrote: post #15
Buge wrote: post #10

Earlier quoted context omitted.

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.

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.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#60

Post by tptacek »

tedunangst wrote: post #54
tptacek wrote: post #37

Earlier quoted context omitted.

Strongest possible disagree. For instance, the Debian OpenSSL bug was an entirely unforced error stemming from applications that chose to use Debian OpenSSL's terrible CSPRNG on top of the OS's CSPRNG. The local attacker scenario you're talking about is a theoretical risk when there are attackers running code in the same OS as your CSPRNG; a far more likely concrete flaw is, for instance, a SecureRandom implementatio…

This seems the complete opposite of your usual advice to use a library. You want every app developer to memorize the intricacies of which of random or urandom or srandom they should use on which OS and whether they need to worry about blocking or short reads and whether the entropy returned is good, or really good, or just good enough? You don't think people are going to dick that up? I'd trust the OpenSSL devs to fi…

The OS already provides a library for securely generating random numbers. On Unix, that library is called "the random driver". Its interface is file-descriptor based.

You'd rather not be in a position to care about cryptographic randomness regardless. So, by all means, use high-level crypto libraries. But those libraries should also be using the random driver, instead of trying to bolt their own CSPRNG on top of it (or, god forbid, trying to avoid the random driver altogether).

Post reply on HN