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

91–100 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#91

Post by nly »

vbuterin wrote: post #88
nly wrote: post #77

Earlier quoted context omitted.

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: htt…

Yes, Bitcoin is one exception because of the digested addresses, but if I'm up to date it's not currently used on the network. There's no opcode in the transaction script to perform recovery, so currently you can't reduce transaction size by omitting public keys. I suppose the primary advantage in Bitcoin is the reduced storage space.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#92

Post by fulafel »

cperciva wrote: post #87
tptacek wrote: post #79

Earlier quoted context omitted.

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

The random/urandom devices do originate from Linux, other implementations should be careful about not making incompatible changes.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#93

Post by sirk390 »

kllrnohj wrote: post #35

Android's SecureRandom uses BouncyCastle prior to 4.2 and OpenSSL in 4.2+ ( http://android-developers.blogspot.com.au/2013/02/security-e... ) It'd be interesting to know what the bug is and if that bug affects Bouncy Castle and/or OpenSSL as well, or if Google screwed up the glue code somehow

This is the paper referenced in the bitcointalk thread: http://www.scribd.com/doc/131955288/Randomly-Failed-The-Stat.... See section 5.4 for Bouncy Castle: Weaknesses/Quality of Entropy Collectors.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#95

Post by makomk »

nly wrote: post #91
vbuterin wrote: post #88

Earlier quoted context omitted.

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: htt…

Yes, Bitcoin is one exception because of the digested addresses, but if I'm up to date it's not currently used on the network. There's no opcode in the transaction script to perform recovery, so currently you can't reduce transaction size by omitting public keys. I suppose the primary advantage in Bitcoin is the reduced storage space.

It's not currently used on the blockchain, but there's a feature in the Bitcoin client that uses public key recovery in order to sign out-of-band messages with Bitcoin addresses.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#96

Post by mydpy »

mydpy wrote: post #94

Can anyone reference me to an article that explores a technical analysis of how their random number generator was exploited? Did it not have full coverage (read: RANDU style error) or otherwise? http://www.pnas.org/content/61/1/25.full.pdf+html

Actually, I found it here. Pretty interesting issue, I recommend the read. I'll summarize the paper here:

Java implementations primarily used on lightweight mobile platforms have a method called SecureRandom which generates pseudo random numbers for cryptographic operations. The integrated seed generator on some platforms provides a systematic means of determining the seed value and predicting seemingly secure outputs.

http://www.scribd.com/doc/131955288/Randomly-Failed-The-Stat...

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#97

Post by tptacek »

cperciva wrote: post #87
tptacek wrote: post #79

Earlier quoted context omitted.

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

So then what you should do is write a "libpcap for randomness" that uses the best-practices method of getting randomness from the OS CSPRNG. On Linux it'll be just a couple lines; on BSD it'll be a few more lines for the "atomicio" equivalent read, and on WINAPI it'd set up and call CryptGenRandom.

There's value in having a uniform interface to all the different OS CSPRNGs.

What I'm saying isn't valuable is duplicative effort to build additional CSPRNG logic in the app layer. As we keep seeing, these app-layer CSPRNGs are additional single points of failure; they don't add defensive depth.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#98

Post by robertotyley »

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…

SpongyCastle is a repackage of BouncyCastle specifically for the Android platform, an unfortunate necessity due to Android shipping with a cut-down version of Bouncy Castle (see https://code.google.com/p/android/issues/detail?id=3280 & http://rtyley.github.io/spongycastle/ ).

...I'm the packager of SpongyCastle (a task a well-trained monkey could do, I don't alter the code other than package-renaming it), and I confess some relief that the issue is with Android's in-built SecureRandom class, rather than anything in (Bouncy|Spongy)Castle.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#100

Post by tedunangst »

tptacek wrote: post #97
cperciva wrote: post #87

Earlier quoted context omitted.

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

So then what you should do is write a "libpcap for randomness" that uses the best-practices method of getting randomness from the OS CSPRNG. On Linux it'll be just a couple lines; on BSD it'll be a few more lines for the "atomicio" equivalent read, and on WINAPI it'd set up and call CryptGenRandom. There's value in having a uniform interface to all the different OS CSPRNGs. What I'm saying isn't valuable is duplicati…

How is OpenSSL RAND_bytes not that uniform interface?
Post reply on HN