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

61–70 of 105 posts

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#61

Post by tptacek »

marshray wrote: post #52
tptacek wrote: post #47

Earlier quoted context omitted.

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?

Modulo the fact that Debian shouldn't be mucking with the inner workings of packages in the first place, sure; stubbing out OpenSSL's CSPRNG with calls to the OS CSPRNG seems like a reasonable plan. It is, by the way, part of the NaCL design too.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#62

Post by tptacek »

fixxer wrote: post #51
fixxer wrote: post #46

Earlier quoted context omitted.

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!)

I'm a season behind on Breaking Bad; I don't like watching half-seasons and would rather just watch the whole thing once it's all on Netflix. So: not too excited.

63 people have finished the crypto challenges; about 9000 people have started them.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#63

Post by tptacek »

mikeash wrote: post #58

Looks like a terrifyingly buggy SecureRandom implementation that results in only 31 bits of entropy when seeding: http://armoredbarista.blogspot.com.au/2013/03/randomly-faile...

As I understand it, Android doesn't use Harmony's CSPRNG. But maybe it did in an earlier version? Maybe that's the problem?

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#64

Post by tptacek »

filipmaertens wrote: post #33

At blog post https://cryptocow.com/?p=201 we've been experimenting with using sensors to upgrade PRNG's, and we frankly can't understand why this isn't been used natively in Android RNG implementations... It's trivial, easy and tremendously increases the RNG quality.

Because a sensor provides an entropy source, not a whole CSPRNG. Most modern CSPRNGs have interfaces to feed entropy into the system, but CSPRNG designs do more than simply route entropy from one place to another.

This is a really common misconception people seem to have about cryptographic random number generation, and a topic Ferguson and Schneier do an extremely good job breaking down in _Cryptography Engineering_.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#65

Post by rwg »

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?

Whenever I see tptacek tweet the current stats, I try to update this spreadsheet:

https://docs.google.com/spreadsheet/ccc?key=0AscYGzcM4zJNdHR...

I've probably missed a few tweets and typo'd a few numbers along the way, but it should be mostly accurate. Note the tabs (at bottom left) for a derived speadsheet (percent of participants at each level) and a chart.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#66

Post by tptacek »

rwg wrote: post #65
fixxer wrote: post #46

Earlier quoted context omitted.

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

Whenever I see tptacek tweet the current stats, I try to update this spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AscYGzcM4zJNdHR... I've probably missed a few tweets and typo'd a few numbers along the way, but it should be mostly accurate. Note the tabs (at bottom left) for a derived speadsheet (percent of participants at each level) and a chart.

For those watching from the stands, 'rwg also sent us a spreadsheet that does AES. Entirely in cell formulas. He also sent us a Postscript file that appeared to be a visualization of AES state but was in fact a pure-Postscript implementation of AES that rendered itself into the Postscript document.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#67

Post by tptacek »

andrewcooke wrote: post #50
tptacek wrote: post #9

Earlier quoted context omitted.

This is a Bitcoin software implementation bug, and an illustration of why you should use your OS's CSPRNG (here, /dev/random) to the exclusion of any other RNG.

"This is a Bitcoin software implementation bug," where are you getting your info from? as far as i can tell previous code was buggy, and android 4.2 "fixed" things by making it impossible (well...) to screw up the PRNG (setSeed in OpenSSL augments state, previously with BouncyCastle it replaced state, afaict). but that doesn't explain why current software has problems (not the kind of problems that should make it ins…

You might be right! I'd be surprised if there was an OS or even framework-level CPSRNG bug in Android, but it's possible, and the obvious bug Patrick mentioned downthread is nowhere to be seen in bitcoinj or SpongyCastle.

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#69

Post by rwg »

tptacek wrote: post #66
rwg wrote: post #65

Earlier quoted context omitted.

Whenever I see tptacek tweet the current stats, I try to update this spreadsheet: https://docs.google.com/spreadsheet/ccc?key=0AscYGzcM4zJNdHR... I've probably missed a few tweets and typo'd a few numbers along the way, but it should be mostly accurate. Note the tabs (at bottom left) for a derived speadsheet (percent of participants at each level) and a chart.

For those watching from the stands, 'rwg also sent us a spreadsheet that does AES. Entirely in cell formulas. He also sent us a Postscript file that appeared to be a visualization of AES state but was in fact a pure-Postscript implementation of AES that rendered itself into the Postscript document.

To be fair, I've only tweeted screenshots of the AES spreadsheet -- you'll be getting the actual .xlsx file with my set 6 answers. AES128.applescript is waiting in the responses@ and cryptopals@ mailboxes right now, along with my set 5 answers.

I don't know what I'll do for set 7 yet. Maybe Excel implementations of the SHA-3 finalists...

Re: Android RNG Weakness Renders Bitcoin Wallets Insecure

#70

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…

the only other thing i see is the openssl securerandom code doesn't properly check the return value. it is possible for RAND_bytes to fail and for the securerandom code to not throw an exception. i think this is quite unlikely to happen. so basically:

1) reading from /dev/urandom takes more than 10ms causing an entropy error

2) a malloc fails causing the error to be saved to the fallback ERR_STATE instead of the thread local ERR_STATE

3) java sees failing code and tries to read the last error but now malloc succeeds so it reads it from its local thread ERR_STATE which succeeds or some other thread has clobbered the fallback ERR_STATE

4) java doesn't throw an exception because it sees no error

the other possibility is the openssl random state is shared between processes due to forking. i hear there is a process called the zygote that warms up the vm and forks to create apps. if it initialises openssl then it is possible child processes could get the same random state.

Post reply on HN