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

81–90 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#81

Post by tptacek »

marshray wrote: post #80
tptacek wrote: post #78

Earlier quoted context omitted.

arc4random predates modern OS CSPRNGs.

So does OpenSSL. I think it's just not reasonable to expect a widely-portable crypto primitive and protocol library to judge the quality of the host /dev/[u]random and delegate to it. Of course, they seed from the host device and try to estimate the entropy it provides. Even that OS with the biased /dev/[u]random using RC4 because it was fast would keep a separate RC4 state in each process' libc to avoid the overhead…

So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#82

Post by marshray »

tptacek wrote: post #81
marshray wrote: post #80

Earlier quoted context omitted.

So does OpenSSL. I think it's just not reasonable to expect a widely-portable crypto primitive and protocol library to judge the quality of the host /dev/[u]random and delegate to it. Of course, they seed from the host device and try to estimate the entropy it provides. Even that OS with the biased /dev/[u]random using RC4 because it was fast would keep a separate RC4 state in each process' libc to avoid the overhead…

So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?

I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS.

Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel developers who try to compensate with 6000 bit entropy pools.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#83

Post by tptacek »

marshray wrote: post #82
tptacek wrote: post #81

Earlier quoted context omitted.

So then, you think NaCL's design decision to rely on /dev/urandom was a mistake?

I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS. Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel develope…

If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work; all sorts of things depend on it. The urandom ship has sailed.

Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#84

Post by marshray »

tptacek wrote: post #83
marshray wrote: post #82

Earlier quoted context omitted.

I think if NaCL ever gets popular that design decision will bite somebody, somewhere, on some OS. Our crypto libraries need to provide their own belt to wear with the OS-provided suspenders. Yes, I know about potential fork() bugs, but our modern VM-crazed deployments introduce that possibility at kernel level too. We need our good crypto implementers shipping good lightweight CSPRNGs, rather than the kernel develope…

If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work ; all sorts of things depend on it. The urandom ship has sailed. Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.

OK, so NaCL will not be guilty and they will be in good company.

I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed.

Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than kernel developers who find entropy pools exciting.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#85

Post by tptacek »

marshray wrote: post #84
tptacek wrote: post #83

Earlier quoted context omitted.

If some OS screws up urandom so much that it bites someone, it'll bite a huge number of different apps, and not just the ones that use NaCL. Like it or not, urandom has to work ; all sorts of things depend on it. The urandom ship has sailed. Meanwhile, better to have just one codebase to review, rather than 100 crappy ones, like the SecureRandom from Harmony.

OK, so NaCL will not be guilty and they will be in good company. I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed. Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than k…

You see my point, right? A lot of your security already depends on urandom working. Everyone knows this, and a lot of effort has gone into validating the kernel random driver (there have been some pretty good systems security papers on it). Given that you already depend on urandom, all a new CSPRNG gets most developers is a second single point of failure.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#86

Post by marshray »

tptacek wrote: post #85
marshray wrote: post #84

Earlier quoted context omitted.

OK, so NaCL will not be guilty and they will be in good company. I'm sure these principles of minimal redundancy will be of great comfort to those users who get their private keys exposed. Do you see the paradox here? Find me these developers who are undoubtedly competent to implement their own CSPRNG, but prefer not to. These are the folks I want implementing the CSPRNG that will be generating my keys, rather than k…

You see my point, right? A lot of your security already depends on urandom working. Everyone knows this, and a lot of effort has gone into validating the kernel random driver (there have been some pretty good systems security papers on it). Given that you already depend on urandom, all a new CSPRNG gets most developers is a second single point of failure.

I get your point and I agree it's at least not a wrong way to look at it. But you say "the kernel random driver" as if there were only one for a crypto app developer to worry about.

We have already seen a huge number of bad keys generated. Is it that obvious at this point that kernel (and embedded system) developers are so much better at this than OpenSSL?

Is it possible that you just tend to look at more broken library and app crypto code during the course of your work? If you worked primarily with broken kernel crypto code, would you perhaps prefer (for your own use) a CSPRNG in a library written by your favorite experts?

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#87

Post by cperciva »

tptacek wrote: post #79
cperciva wrote: post #76

Earlier quoted context omitted.

Strongest possible disagree. Ok, we disagree. It wouldn't be the first time. ;-) 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 I think the biggest problem was that OpenSSL used OpenSSL's CSPRNG after Debian broke it. Having applications all open+read+close /dev/random is not going to prevent that. a far mor…

Linux random/urandom is supposed to prevent short-reads for exactly this reason. You raise an interesting point, but I'm not persuaded that the risk of quietly failing to read from the random device is greater than the risks of adopting an entire new CSPRNG to sit on top of the OS's CSPRNG.

Linux random/urandom is supposed to prevent short-reads for exactly this reason.

Oh great, yet another way that Linux developers are going to write broken code because they think the whole unix world behaves like Linux...

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#88

Post by vbuterin »

nly wrote: post #77
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…

Another interesting thing about DSA is that the signatures allow for public key recovery i.e. given a signed message, you can (usually within 1 or 2 possibilities) determine the public key of the signer. It's a bit like a handwritten signature where everybody can read your name amongst the scrawl. Most of the time this property is useless, because you want to verify the signature against a known-good key, but it does…

Actually, the key-recovery process is quite useful. The reason is that instead of having your public key be the public key itself, you can use the hash of your public key (ie. Bitcoin address) instead. This cuts the required "public key" length in half for the same level of security. The verification protocol then becomes

def verify(msg,sig,addr): return pubkey_to_address(ecdsa_recover(msg,sig)) == addr

See also: https://github.com/vbuterin/pybitcointools

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#89

Post by vbuterin »

javert wrote: post #8
LAMike wrote: post #3

this could be a big blow to Bitcoin adoption... Is this a part of Android that can't be touched by anyone but Gooogle? Or is it a piece of software that can be improved upon by open source devs?

I don't think it's a very big deal. For the most part, people who use bitcoin now are still very early adopters and are techies. Also, IMHO, it would be idiotic to have significant bitcoin value stored on an Android phone, and very few people (if anyone) would do that.

> Also, IMHO, it would be idiotic to have significant bitcoin value stored on an Android phone, and very few people (if anyone) would do that.

Correct. The standard recommendation is to store significant savings in wallets that you use as little as possible (ideally offline).

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#90

Post by brazzy »

Dylan16807 wrote: post #22
w0rd-driven wrote: post #17

Earlier quoted context omitted.

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…

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()); }

Post reply on HN