[ANNOUNCE] Android key rotation

[Mike Hearn]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

http://bitcoin.org/en/alert/2013-08-11-android

We recently learned that a component of Android responsible for generating secure random numbers contains critical weaknesses, that render all Android wallets generated to date vulnerable to theft. Because the problem lies with Android itself, this problem will affect you if you have a wallet generated by any Android app. An incomplete list would be Bitcoin Wallet, blockchain.info wallet, BitcoinSpinner and Mycelium Wallet.

In order to re-secure existing wallets, key rotation is necessary. This involves generating a new address with a repaired random number generator and then sending all the money in your wallet back to yourself. If you use an Android wallet then we strongly recommended you upgrade to the latest version available in the Play Store as soon as one becomes available. Once your wallet is rotated, you will need to contact anyone who has stored addresses generated by your phone and give them a new one.

If you use Bitcoin Wallet by Andreas Schildbach, key rotation will occur automatically soon after you upgrade. The old addresses will be marked as insecure in your address book. You will need to make a fresh backup.

Updates for other wallet apps should be released shortly.

Some technical details of what exactly has gone wrong inside Android will be released once the upgrade process is reasonably compete. I will keep track of the upgrade status of each wallet app I know about in the post below.
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCgAGBQJSB7jRAAoJEPLkhhyZiIFvpk8IAI34L0HsEj5wztFl18jQxj74
svaY+eY1mwgWZjjyZlCRlP42B3u5zF2jlh2+taRgM9DaXlECqa3euGe+EmHWirTU
HTTNNg2ZFf7jvruUZ2tanl4Sv34/q/q8w81zL6uJAKK98ZBWuMQ9oPghW1erCAHv
Ke5eoLzGdnwpAN817SLGL2iUgwMpJLu7Jx2HEhF2Yz7Yl1+ScLHzlXSZP65BlpI7
lNeJweQsC0PHPnumde/UIRdcTQqhciY/0xM7HHyrrn00AW56vu4l+/Hb9Mr9rpds
Rx2UEvFXQ5KWX7e8E3+Wx2Rs/w5cYRwwsfzwWIYkoZaJ3ssaPaYAEr5YMO1bz24=
=AFBd
-----END PGP SIGNATURE-----

[1715386725]

1715386725

[1715386725]

1715386725

[1715386725]

1715386725

[1715386725]

1715386725

[Mike Hearn]

Here are the rollout statuses of each wallet I'm aware of:

Bitcoin Wallet by Andreas Schildbach

An update has been prepared and is now rolling out on the play store. When you are notified, let the app update and the rest will happen automatically. Learn more.

BitcoinSpinner / Mycelium Wallet

An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.

blockchain.info wallet

An update is on the Play Store that will walk you through the key rotation process when you open it. Upgrade immediately and follow the on screen instructions.


Please note that apps where you don't control the private keys at all are not affected. For example, exchange frontends like the Coinbase or Mt Gox apps are not impacted by this issue because the private keys are not generated or controlled by you at all.

Basic rule of thumb - if you'd lose the money if the phone/tablet were destroyed (assuming no backups), and that device is an Android device, then you need to upgrade ASAP.

For blockchain.info wallets, even if the keys were generated on a desktop/laptop computer or iPhone, if any payments were made from an Android device, you are also affected. Likewise, if you have imported private keys from elsewhere into an Android wallet and made payments with it, you may also be affected.


I'd like to publicly thank Jean-Pierre Rupp (Xeno-Genesis on this forum) for bringing one of the vulnerabilities to our attention last week. His notification to us about the RSA paper started the effort needed to re-key peoples wallets. I'd also like to thank johoe and BurtW for their investigations into how peoples wallets were being compromised.

[beerbeerbeer]

done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.

[Dougie]

This is very useful information. Thanks for the announcement.

[DiamondCardz]

Oh dear. Thanks for the update.

[Blindfolded]

Thanks for the heads up.

[Boelens]

Oh wow, I'm glad all the warnings are spreading so quickly, everyone has to be informed ASAP.

[piotr_n]

done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.

You're joking, aren't you?

This post is over one month old, while this one over half a year...
Watchfulness my ass

[Boelens]

Thank god I have an iPhone

I don't even have a smartphone ;P

[E.Sam]

Just wondering, would this affect Electrum as well?

http://electrum.org/android.html

[apetersson]

If you are using Mycelium Wallet, a fix has been published to the play store (still pending review) and to mycelium.com

if you download it from mycelium.com, you can check the sha1sum

Code:

dba000cad4cbf94a7b4c621f57482322c0a96678  mbw-v0.6.5.apk

There will be a wizard guiding you through the process in an upcoming version, but for now, you can simply download version 0.6.5 (or greater) and move the keys to newly generated addresses.

• generate a new key
• backup this key (to sdcard or similar)
• manually send funds to the new secure address.
• move your empty old key to the Archive category

Please take care. The most likely chance of lost bitcoins is the loss of private keys. Don't use our wallet without a backup of the keys.

[TippingPoint]

a component of Android responsible for generating secure random numbers contains critical weaknesses

Thank you.

[n4ru]

If an address is generated by a computer or other source, and then imported into a blockchain wallet, is it still vulnerable?

I ask because of change addresses.

[Boelens]

If an address is generated by a computer or other source, and then imported into a blockchain wallet, is it still vulnerable?

I think only if it's generated by Android.

[HeroC]

Woah, I have 2 addresses with only 0.002 in them that I generated a year ago. Are they safe? What should I do?

I also imported a vanity address to blockchain.info. Is that safe? I only made one transaction out of it. I generated many other addresses through blockchain.info but never sent anything from them. Are they safe?

[Mike Hearn]

Because Bitcoin transactions require random numbers to create, if you generated spends with an imported key from Android then the key itself may be compromised, but this isn't a given, see here:

http://www.reddit.com/r/Bitcoin/comments/1k51dh/bad_signatures_leading_to_558_btc_theft_so_far/cblgtut

[Xer0]

For blockchain.info wallets, even if the keys were generated on a desktop/laptop computer or iPhone, if any payments were made from an Android device, you are also affected. Likewise, if you have imported private keys from elsewhere into an Android wallet and made payments with it, you may also be affected.

Don't get this...
Wallet created with Bitcoin-QT; imported to Blockchain, but created new Address in Browser - still vulnerable?

[BurtW]

For blockchain.info wallets, even if the keys were generated on a desktop/laptop computer or iPhone, if any payments were made from an Android device, you are also affected. Likewise, if you have imported private keys from elsewhere into an Android wallet and made payments with it, you may also be affected.

Don't get this...
Wallet created with Bitcoin-QT; imported to Blockchain, but created new Address in Browser - still vulnerable?

No matter when or where created if you SPENT BTC from an address using a wallet on an android device then the private key may be known.

Try this:

Basically every bitcoin transaction is signed in order to prove you have the private key and can transfer the funds.  There is a bug in the secure random number generator on the android phones that causes it to sometimes use the same random number to sign a transaction.  If you sign two different transactions with the same private key and the same random number then it is very easy to just calculate the private key from the two signatures.

[elebit]

Could you please clarify:

1. Is this the same, or a different, issue from the one being discussed in the "Bad signatures" thread?

2. Is it absolutely and completely true that this is an Android issue, ie. hosted Blockchain.info wallets and other wallet software written in Java is not affected?

3. I generated my wallet keys off-device. Am I still vulnerable?

4. I generated my wallet keys on-device but have only received funds and not sent any, so no transactions were actually generated by the Android application. Am I still vulnerable?

5. If it turns out from any of the above two reasons that I am not vulnerable, will the update to Android Wallet specifically still rotate my wallet? There are probably a lot of wallets out there who would be greatly hurt by unnecessary transaction fees.

[n4ru]

So basically, Google pulled a Sony...

[Mike Hearn]

Could you please clarify:

1. Is this the same, or a different, issue from the one being discussed in the "Bad signatures" thread?

2. Is it absolutely and completely true that this is an Android issue, ie. hosted Blockchain.info wallets and other wallet software written in Java is not affected?

3. I generated my wallet keys off-device. Am I still vulnerable?

4. I generated my wallet keys on-device but have only received funds and not sent any, so no transactions were actually generated by the Android application. Am I still vulnerable?

5. If it turns out from any of the above two reasons that I am not vulnerable, will the update to Android Wallet specifically still rotate my wallet? There are probably a lot of wallets out there who would be greatly hurt by unnecessary transaction fees.

1. It's the same issue

2. It's an Android issue, not a Java issue.

3. The key would not have an issue in this case. However if you spent money from it then there's a small chance the key may have been exposed. However someone has been monitoring the network for this and claims it only happens a few times a month worldwide, what's more, someone appears to be stealing the money when it does happen. So if you haven't already suffered a theft, you probably haven't been exposed in this way, and simply upgrading and rotating the wallet is sufficient.

4. Your key may be vulnerable.

5. All wallets will be rotated automatically. The Bitcoin Wallet app doesn't really support importing arbitrary private keys. You can do it by re-using the backup mechanism, but key imports/exports in general have all kinds of problems and if you do it, you are "on your own". It's not an official feature of the app.

[Andreas Schildbach]

I see a lot of questions here about which keys are affected and which not.

As far as Bitcoin Wallet goes, it will rotate your keys no matter how you created them and if you used them for signing. This is because there is no supported way of importing keys from other sources than itself (backup), so all keys must have been created using the flaky random number generator.

I can't tell about the other apps, but I hope they will rotate all keys as well.

[AliceWonder]

Could this be what was behind all those random 1 mBTC payments that were going around?

As they are spent, if the wallet was Android they are now multiple spends from same address possibly allowing attacker to figure out private key.

[n4ru]

Could this be what was behind all those random 1 mBTC payments that were going around?

As they are spent, if the wallet was Android they are now multiple spends from same address possibly allowing attacker to figure out private key.

Interesting thought... it would make a bit of sense.

[millsdmb]

pink is a really crappy color, fwiw.

[piotr_n]

pink is a really crappy color, fwiw.

indeed - it's barely visible.

[DiamondCardz]

I noticed it instantly, actually. 

[al.matic]

So basically, Google pulled a Sony...

https://i.imgur.com/e9jUO.png

So, this is the same type of attack as was Sony Playstation network hack (ECDSA random numbers not being random) - so you would expect that developers test their software for the same weakness, right?

AFAIK it is a relatively new algorithm chosen because of short signatures produced, so it might even get broken (even with working random number generators). Something should be done about that...

[n4ru]

So basically, Google pulled a Sony...

So, this is the same type of attack as was Sony Playstation network hack (ECDSA random numbers not being random) - so you would expect that developers test their software for the same weakness, right?

AFAIK it is a relatively new algorithm chosen because of short signatures produced, so it might even get broken (even with working random number generators). Something should be done about that...

The exploit isn't in the algorithm, it's in generating a secure random number. It also wasn't the PSN hack, it was the PS3 hack.

With Sony, they used the same number every single time. It simply wasn't random, and was a horrible, or rather, *not* an implementation of the encryption in the right manner.

With Android, the same random number apparently comes up once in a while. Still horrible considering the money involved (probably worse), but there's only a chance to get the same random number (as opposed to guaranteed with Sony).

[No_2]

Interesting bug. Thanks for the info.

[millsdmb]

I noticed it instantly, actually. 

I did too, just couldnt read it. Thought it was a new ad at first =P

[theymos]

It's hard to get a good color due to the gradient.

[justusranvier]

This vulnerability is yet another reason address reuse in Bitcoin clients must be eliminated.

Prior to this, using non-deterministic wallets was either a privacy disaster (single key model) or else a usability nightmare (random key model).

Now anything which encourages address reuse should be considered negligent.

[Anon136]

in case anyone is confused about the color coding.

[BurtW]

This vulnerability is yet another reason address reuse in Bitcoin clients must be eliminated.

Prior to this, using non-deterministic wallets was either a privacy disaster (single key model) or else a usability nightmare (random key model).

Now anything which encourages address reuse should be considered negligent.

Not really.  This is a problem with a specific implementation of a specific secure random number generator (android).

[millsdmb]

in case anyone is confused about the color coding.

I withdrew all my BTC from vulnerable addresses.

This image reminds me how my crazy (in hindsight) mother did the same with her cash from the bank on Sept 11.
 

[piotr_n]

This vulnerability is yet another reason address reuse in Bitcoin clients must be eliminated.

Prior to this, using non-deterministic wallets was either a privacy disaster (single key model) or else a usability nightmare (random key model).

Now anything which encourages address reuse should be considered negligent.

You must be joking.
If you cannot use the same private key again, to sign a different stuff, then it is not even a digital signature application - you can as well start using random and their hashes, or something..

Of course it must work multiple times - just like PGP/RSA has been working, ever since it was invented.
And nobody says that you using the same PGP key twice "should be considered negligent" - it would just defeat the purpose of a digital signature

[AliceWonder]

This vulnerability is yet another reason address reuse in Bitcoin clients must be eliminated.

Prior to this, using non-deterministic wallets was either a privacy disaster (single key model) or else a usability nightmare (random key model).

Now anything which encourages address reuse should be considered negligent.

Not really.  This is a problem with a specific implementation of a specific secure random number generator (android).

Yes really. Payment addresses should not be re-used after money is spent. If you do not re-use the address then you can not fall victim to this if your random generator is not as random as it should be.

But that has nothing to do with deterministic wallets. Non deterministic wallets do not require address re-use.

[justusranvier]

Not really.  This is a problem with a specific implementation of a specific secure random number generator (android).

If addresses are never reused, it doesn't matter if individual private keys are compromised after the fact.

[justusranvier]

But that has nothing to do with deterministic wallets. Non deterministic wallets do not require address re-use.

The reason that clients reuse addresses is because random key wallets are unsuitable for general use.

Requiring users to update their backups after every n transactions results in permanently lost funds.

The solution is to implement BIP32.

[kangasbros]

This vulnerability is yet another reason address reuse in Bitcoin clients must be eliminated.

Prior to this, using non-deterministic wallets was either a privacy disaster (single key model) or else a usability nightmare (random key model).

Now anything which encourages address reuse should be considered negligent.

Not really.  This is a problem with a specific implementation of a specific secure random number generator (android).

Single-address-per-transaction policy is better for privacy, and also protects from a class of security issues AFAIK. IMHO it is kind of supporting that BItcoinJ dev team hasn't been very keen on implementing proper multi-address support. But then again, it is open source, if you don't like it develop a batch... Myself I don't use BitcoinJ but other solutions.

[Yash]

This is very risky... I was thinking about installing a wallet on my phone but it's too early to do that now.

[Mike Hearn]

The new bitcoinj release that will be announced shortly has some initial code for BIP32. It's definitely something I want to integrate. It's difficult on mobile devices because they don't have any swapfile, so you can't just use as much memory as you want. You have to define a key window in which money can be received. Coins sent to keys that fall outside that window won't show up which is obviously very problematic. All in all, it's delicate and will require some careful experimentation and testing to make it work.

[BurtW]

Not really.  This is a problem with a specific implementation of a specific secure random number generator (android).

If addresses are never reused, it doesn't matter if individual private keys are compromised after the fact.

The point is that with a proper RNG reuse is safe.

With a bad RNG no address is safe because it leads to bad signatures AND bad private keys.

[elebit]

Mike Hearn, Goonie, thanks for answering my questions.

So if I understand this correctly, if you generated your key an Android, OR if you generated a transaction on Android, one should consider that key insecure. Correct?

Will the wallet rotation on the Android Bitcoin Wallet incur a transaction fee?

[Mike Hearn]

Transactions that re-use K values seem to result in a theft a few hours later. So, if your money hasn't been stolen and the key was not weakly generated, it's probably OK.

Yes it will incur the usual min tx fee.

[Moogle]

Pretty annoying for those people who imported vanity addresses into their android devices

[sinner]

i'm confused--are all blockchain.info wallets vulnerable?  (even if you dont have an android phone)

[Boelens]

i'm confused--are all blockchain.info wallets vulnerable?  (even if you dont have an android phone)

No, just those generated by an Android phone.

[millsdmb]

i'm confused--are all blockchain.info wallets vulnerable?  (even if you dont have an android phone)

Here are the rollout statuses of each wallet I'm aware of:

blockchain.info wallet: An update was released today that adds a new key using a fixed RNG, so you can manually rotate now. Another update will follow in the coming days that will automatically re-send all coins controlled by the previous keys to the new one.

Please note that apps where you don't control the private keys at all are not affected. For example, exchange frontends like the Coinbase or Mt Gox apps are not impacted by this issue because the private keys are not generated or controlled by you at all.

Basic rule of thumb - if you'd lose the money if the phone/tablet were destroyed (assuming no backups), and that device is an Android device, then you need to upgrade ASAP.

For blockchain.info wallets, even if the keys were generated on a desktop/laptop computer or iPhone, if any payments were made from an Android device, you are also affected. Likewise, if you have imported private keys from elsewhere into an Android wallet and made payments with it, you may also be affected.

[STT]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

[jbis1]

Reading through the entire thread, I am still not clear on this. If I logged into and made transactions using the blockchain.info website through my Android device's web browser, does this affect me? I have never used the blockchain.info app.

[apetersson]

If you are using Mycelium Wallet, a fix has been published to the play store (still pending review) and to mycelium.com

if you download it from mycelium.com, you can check the sha1sum

Code:

dba000cad4cbf94a7b4c621f57482322c0a96678  mbw-v0.6.5.apk

There will be a wizard guiding you through the process in an upcoming version, but for now, you can simply download version 0.6.5 (or greater) and move the keys to newly generated addresses.

• generate a new key
• backup this key (to sdcard or similar)
• manually send funds to the new secure address.
• move your empty old key to the Archive category

Please take care. The most likely chance of lost bitcoins is the loss of private keys. Don't use our wallet without a backup of the keys.

[P_Shep]

Oopsie!
I've extracted all mah money... Waiting for update.

[Sukrim]

Annoyingly the Schildbach wallet seems to now enforce(!) a 0.0001 BTC default fee!

Well, these issues aside - thanks for informing us.

[Remember remember the 5th of November]

Annoyingly the Schildbach wallet seems to now enforce(!) a 0.0001 BTC default fee!

Well, these issues aside - thanks for informing us.

Well what do you expect? The minimum I always pay is 0.0006 or 0.0005 on the -Qt client. Non-fee transactions usually means hours to days waiting for confirmations.

[millsdmb]

Annoyingly the Schildbach wallet seems to now enforce(!) a 0.0001 BTC default fee!

Well, these issues aside - thanks for informing us.

I cant find any wallet other than bitcoin-qt that lets you put a 0.00 tx fee. Surprising to see people in here wondering about fees. it's a penny. Go sell something on PayPal and tell me about fees.

[JoelKatz]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

This is a common misconception. Real-world computers actually have access to any number of sources of real randomness. For example, the offset between the crystal oscillator that drives the CPU and the crystal oscillator that drives the network card is determined by microscopic zone temperature variations that are believed to be truly random. The latency of a hard disk drive is dependent on turbulent airflow drag on the spindle which is also believed to be truly random. Some CPUs and chipsets have true random number generators on them, usually obtained from shot noise which is also believed to be truly random. (And even if they're not truly random, they are entirely unpredictable.)

[piotr_n]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

This is a common misconception. Real-world computers actually have access to any number of sources of real randomness. For example, the offset between the crystal oscillator that drives the CPU and the crystal oscillator that drives the network card is determined by microscopic zone temperature variations that are believed to be truly random. The latency of a hard disk drive is dependent on turbulent airflow drag on the spindle which is also believed to be truly random. Some CPUs and chipsets have true random number generators on them, usually obtained from shot noise which is also believed to be truly random. (And even if they're not truly random, they are entirely unpredictable.)

Which does not change the fact that there are corporations out there selling certified random number generators, for thousands of dollars per piece.
Try to explain to a bank that a PC can generate random data equally well...

[millsdmb]

Annoyingly the Schildbach wallet seems to now enforce(!) a 0.0001 BTC default fee!

Well, these issues aside - thanks for informing us.

Well what do you expect? The minimum I always pay is 0.0006 or 0.0005 on the -Qt client. Non-fee transactions usually means hours to days waiting for confirmations.

I second this. While mining with deepbit, their tx fees are not included. One payment sat for almost 4 days before being picked up by eligius pool. Just send the penny.

[n4ru]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

Nothing can generate a random number. Us included. Only pseudo-random.

[Mike Hearn]

Fees have to be attached due to a strange quirk of bitcoind mining code - it only allocates 27kb per block for free transactions. There's no obvious reason that should be the case and I'm sure it'll get fixed at some point. Even a penny is a high fee to pay, IMO.

[JoelKatz]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

Nothing can generate a random number. Us included. Only pseudo-random.

So you believe that radioactive decay is deterministic? If so, you are in the minority. Say I have two uranium atoms and one of the decays before the other, what do you think accounts for that?

[elebit]

I cant find any wallet other than bitcoin-qt that lets you put a 0.00 tx fee. Surprising to see people in here wondering about fees. it's a penny. Go sell something on PayPal and tell me about fees.

Here are some reasons why:

You might only have only a couple of pennies in your wallet (for novelty purposes).

Those who have moved beyond fiat pricing might like the idea of keeping their 1.0 bitcoins instead of having 0.99999 bitcoins.

Old money which is not broken in many thin slices don't need to pay fees, they don't need to wait more than a few hours anyway.

[JoelKatz]

If an address is generated by a computer or other source, and then imported into a blockchain wallet, is it still vulnerable?

I think only if it's generated by Android.

Unfortunately, it is still vulnerable. The signature algorithm uses the random number generator as well and if a signature is generated improperly, it can compromise the private key. This was, in fact, the way the vulnerability was exploited.

"... some signatures have been observed to have colliding R values, allowing the private key to be solved and money to be stolen." -- Mike Hearn

[candtalan]

..... Payment addresses should not be re-used after money is spent. If you do not re-use the address then you can not fall victim to this if your random generator is not as random as it should be.

Novice here.
I guess, or understand, that 'receive' addresses can be safely used more than once? Presumably the receive process is much more passive than a payment process? Is my understanding ok here please?

[NeedChangeNow]

Is this flaw related to why "Error Response Invalid signature" keeps happening to certain users attempting to send funds from the Blockchain.info Android app? (thread here: https://bitcointalk.org/index.php?topic=240548.0). I'd love to be able to get my btc out of this wallet but it seems less likely by the day.

[justusranvier]

I guess, or understand, that 'receive' addresses can be safely used more than once?

Receive addresses should be used exactly one time, then never again.

If you reuse addresses for receiving bitcoins you have no financial privacy, and you're vulnerable to issues like this.

[elor70]

Thanks for the warning

[Lauda]

Oh boy, we didn't need this.
Thanks for the heads up.

[candtalan]

I guess, or understand, that 'receive' addresses can be safely used more than once?

Receive addresses should be used exactly one time, then never again.
If you reuse addresses for receiving bitcoins you have no financial privacy, and you're vulnerable to issues like this.

Oh bother. Thanks. In my case I have never used an android device for any Bitcoin stuff so I trust I am safe from the current non random number issue(?)
However, it has been convenient to gather occasional small amounts from the (get free bitcoins) site http://netlookup.se/free-bitcoins/247552
Just to be very clear here, I now should not offer the same receive address more than once then?
tia
(edit)
I note that  this site mentioned above works on the basis of a receive address being used repeatedly.... Is it a scam site? or is it just  doing rather bad things?

[n4ru]

I guess, or understand, that 'receive' addresses can be safely used more than once?

Receive addresses should be used exactly one time, then never again.
If you reuse addresses for receiving bitcoins you have no financial privacy, and you're vulnerable to issues like this.

Oh bother. Thanks. In my case I have never used an android device for any Bitcoin stuff so I trust I am safe from the current non random number issue(?)
However, it has been convenient to gather occasional small amounts from the (get free bitcoins) site http://netlookup.se/free-bitcoins/247552
Just to be very clear here, I now should not offer the same receive address more than once then?
tia
(edit)
I note that  this site mentioned above works on the basis of a receive address being used repeatedly.... Is it a scam site? or is it just  doing rather bad things?

Oh boy... justusranvier is totally confusing the newbies.

[rumak]

Thanks for the quicks news and update.

[Sukrim]

Well what do you expect? The minimum I always pay is 0.0006 or 0.0005 on the -Qt client. Non-fee transactions usually means hours to days waiting for confirmations.

I wouldn't mind actually waiting some time if that meant my transaction was free. I didn't want or plan to transfer these funds in the first place and I don't mind them being stuck for some time in limbo. Once the TX is out there, it would be hard to double spend it anyways.

I cant find any wallet other than bitcoin-qt that lets you put a 0.00 tx fee. Surprising to see people in here wondering about fees. it's a penny. Go sell something on PayPal and tell me about fees.

Schildbach allowed this (0 fees) too some time ago so I consider it a regression. If I use PayPal, I pay for a service that goes beyond simple money transfer (I get fraud protection etc.).

I second this. While mining with deepbit, their tx fees are not included. One payment sat for almost 4 days before being picked up by eligius pool. Just send the penny.

This is just stupidity on deepbit's end - they could always include their payouts for free in their own blocks and I suggested something like that (pools accepting each other's payouts for free) long time ago. Back then it was anyways easy to get anything transacted for free, so they never went forward with it. I don't want to pay a whole penny for a few bytes of storage that will be pruned away sooner or later anyways.

Fees have to be attached due to a strange quirk of bitcoind mining code - it only allocates 27kb per block for free transactions. There's no obvious reason that should be the case and I'm sure it'll get fixed at some point. Even a penny is a high fee to pay, IMO.

The wallet used to have a setting that let me set fees to 0 on my own risk. This setting seems to be gone...
Anyways, fee handling and transaction priorization is a big mess in my opinion still in Bitcoin, especially in the reference client that everyone seems to use unreflected without even thinking about the settings.


About receiving coins at the same address:
In the end it means that you potentially loose privacy (e.g. the free bitcoins site could link your IP to your address, then you sell a obile phone on the web and let them pay to the same address - now the free bitcoin site can see that you received some more coins + the buyer of the phone sees that you probably used this site). Security wise it means that once you send something from your address, you expose the public key belonging to that address. In this case, the signature generated with it is weakening security - there is also the possibility of a breach of ECDSA keys in general. As long as nothing has been transfered off an address, it is as safe as possible from a current security standpoint.

[ashish12]

totally agree 

Well what do you expect? The minimum I always pay is 0.0006 or 0.0005 on the -Qt client. Non-fee transactions usually means hours to days waiting for confirmations.

I wouldn't mind actually waiting some time if that meant my transaction was free. I didn't want or plan to transfer these funds in the first place and I don't mind them being stuck for some time in limbo. Once the TX is out there, it would be hard to double spend it anyways.

I cant find any wallet other than bitcoin-qt that lets you put a 0.00 tx fee. Surprising to see people in here wondering about fees. it's a penny. Go sell something on PayPal and tell me about fees.

Schildbach allowed this (0 fees) too some time ago so I consider it a regression. If I use PayPal, I pay for a service that goes beyond simple money transfer (I get fraud protection etc.).

I second this. While mining with deepbit, their tx fees are not included. One payment sat for almost 4 days before being picked up by eligius pool. Just send the penny.

This is just stupidity on deepbit's end - they could always include their payouts for free in their own blocks and I suggested something like that (pools accepting each other's payouts for free) long time ago. Back then it was anyways easy to get anything transacted for free, so they never went forward with it. I don't want to pay a whole penny for a few bytes of storage that will be pruned away sooner or later anyways.

Fees have to be attached due to a strange quirk of bitcoind mining code - it only allocates 27kb per block for free transactions. There's no obvious reason that should be the case and I'm sure it'll get fixed at some point. Even a penny is a high fee to pay, IMO.

The wallet used to have a setting that let me set fees to 0 on my own risk. This setting seems to be gone...
Anyways, fee handling and transaction priorization is a big mess in my opinion still in Bitcoin, especially in the reference client that everyone seems to use unreflected without even thinking about the settings.


About receiving coins at the same address:
In the end it means that you potentially loose privacy (e.g. the free bitcoins site could link your IP to your address, then you sell a obile phone on the web and let them pay to the same address - now the free bitcoin site can see that you received some more coins + the buyer of the phone sees that you probably used this site). Security wise it means that once you send something from your address, you expose the public key belonging to that address. In this case, the signature generated with it is weakening security - there is also the possibility of a breach of ECDSA keys in general. As long as nothing has been transfered off an address, it is as safe as possible from a current security standpoint.

[kangasbros]

I guess, or understand, that 'receive' addresses can be safely used more than once?

Receive addresses should be used exactly one time, then never again.
If you reuse addresses for receiving bitcoins you have no financial privacy, and you're vulnerable to issues like this.

Oh bother. Thanks. In my case I have never used an android device for any Bitcoin stuff so I trust I am safe from the current non random number issue(?)
However, it has been convenient to gather occasional small amounts from the (get free bitcoins) site http://netlookup.se/free-bitcoins/247552
Just to be very clear here, I now should not offer the same receive address more than once then?
tia
(edit)
I note that  this site mentioned above works on the basis of a receive address being used repeatedly.... Is it a scam site? or is it just  doing rather bad things?

If you are receiving miniscule amounts, then it doesn't matter. You can use common sense. The site isn't scam.

[candtalan]

If you are receiving miniscule amounts, then it doesn't matter. You can use common sense. The site isn't scam.

Ah thanks, I was hoping that, it also helps to confirm my limited understanding of this stuff.

[ISAWHIM]

Nothing can generate a random number. Us included. Only pseudo-random.

That is an opinion...

Fact is... any number which is not sequential and read from a list, is random. Might not be "as random as you would like", but it is still random. Even pseudo-random selection is non-sequential and not read from a list. (Unless you start at the beginning, start at the same seed/list or the seed is the same seed/list as another seed. Which is the repeat of a list.)

But I digress...

The problem is that these devices and programs, made by programmers with little knowledge, failed to understand the devices they were working with. That is what happens when you just copy-n-paste code and don't actually KNOW what it is doing.

One year... This has been known about android since the first program "solitaire" which used random numbers to shuffle, released before the phone was even physically made, in the emulator.

Oh, and the comment about "Glad I have an i-phone"... LOL... Might want to look at all the exploits your phone has, before you open your mouth. You are worse-off than the android phone, because you are naive and oblivious to the reality of the flaws of the device in your hands. Yay, you don't have THIS FLAW... You have your own, and no-one is fixing shit for you, unless you pay them for the app to secure the flaws.

[elebit]

2. It's an Android issue, not a Java issue.

Also, could we please get a link to the relevant Android bug tracker item?

It's a bit frustrating to piece together rumors in order to know what actually happened here.

[E.Sam]

Just wondering, would this affect Electrum as well?

I m asking as it uses Google Scripting Layer & Python for Android

http://electrum.org/android.html

[n4ru]

Just wondering, would this affect Electrum as well?

I m asking as it uses Google Scripting Layer & Python for Android

http://electrum.org/android.html

The issue appears to be in the java implementation of secureRandom that Google uses.

[Mike Hearn]

Re: Electrum. I don't know how Electrum on Android does signing. It might well have a similar problem, especially if it uses OpenSSL.

[Andreas Schildbach]

Re: Electrum. I don't know how Electrum on Android does signing. It might well have a similar problem, especially if it uses OpenSSL.

At least its not running on Java, afaik. So it can't be affected by the same issues.

[ReCat]

Thank god I have an iPhone

As far as apple is concerned. Bitcoin wallets don't exist for iOS. Security through obscurity is good, I think.

[btcsql]

Mike Hearn, you are the man now dog!

[bitcool]

How "critical" is it? Has there been any successful attack using this weakness?

[niko]

How "critical" is it? Has there been any successful attack using this weakness?

Sounds extremely critical, see links below.

done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.

You're joking, aren't you?

This post is over one month old, while this one over half a year...
Watchfulness my ass

[Phinnaeus Gage]

So basically, Google pulled a Sony...

So, this is the same type of attack as was Sony Playstation network hack (ECDSA random numbers not being random) - so you would expect that developers test their software for the same weakness, right?

AFAIK it is a relatively new algorithm chosen because of short signatures produced, so it might even get broken (even with working random number generators). Something should be done about that...

The exploit isn't in the algorithm, it's in generating a secure random number. It also wasn't the PSN hack, it was the PS3 hack.

With Sony, they used the same number every single time. It simply wasn't random, and was a horrible, or rather, *not* an implementation of the encryption in the right manner.

With Android, the same random number apparently comes up once in a while. Still horrible considering the money involved (probably worse), but there's only a chance to get the same random number (as opposed to guaranteed with Sony).

As I get my head wrapped around this, what comes to mind is after reading the above is that if a random number is picked from a finite set of 10K elements, e.g., a duplicate is more apt to appear then choosing a random number from a finite set of 10^100,000 elements. Does this make sense?

[kano]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

Nothing can generate a random number. Us included. Only pseudo-random.

So you believe that radioactive decay is deterministic? If so, you are in the minority. Say I have two uranium atoms and one of the decays before the other, what do you think accounts for that?

Ah, that's how Apple solved it?
Their phones have uranium in them

[Xer0]

explains the price...

[ionstorm]

i randomly received .15 btc yesterday to one of my android generated addresses.  Why would I randomly get free money?  this never happened to me before, is this related to the flaw?

[Sukrim]

i randomly received .15 btc yesterday to one of my android generated addresses.  Why would I randomly get free money?  this never happened to me before, is this related to the flaw?

Most likely not, either someone wanted to give a present to you or something else happened. It is not very likely that you would get MORE funds through this issue!

[EagleTM]

Regarding Electrum:

We need to look into this further but as far as I'm aware Electrum relies on python's random implementation which is usually the operating system's PRNG. This would make running Electrum on Android vulnerable to the same vectors as described in this post for other wallets.

Even If you created the seed on another platfrom it may be possible to reveal the ECDSA private key of one of the addresses by spending (signing) multiple times from one address on Android. The seed itself should be safe.

The userbase of Electrum on Android (SL4A) is small because of the cumbersome setup. Still, if you are a user and want to be safe don't spend from Android until further news are available and secure funds from addresses which you have spent from in Android and still have funds on.

[millsdmb]

i randomly received .15 btc yesterday to one of my android generated addresses.  Why would I randomly get free money?  this never happened to me before, is this related to the flaw?

did you google the sending address?

[EagleTM]

i randomly received .15 btc yesterday to one of my android generated addresses.  Why would I randomly get free money?  this never happened to me before, is this related to the flaw?

Though unlikely I suppose if you (not so) "randomly" happened to create a collision on Android you may have gained .15 BTC of an other user and both of you could spend it. It may well be related but certainly a coincidence. Would be interesting if this is followed up...

[justusranvier]

Of course it must work multiple times - just like PGP/RSA has been working, ever since it was invented.
And nobody says that you using the same PGP key twice "should be considered negligent" - it would just defeat the purpose of a digital signature

A better analogy would compare Bitcoin addresses to session keys.

[ironfalcon]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

http://bitcoin.org/en/alert/2013-08-11-android

We recently learned that a component of Android responsible for generating secure random numbers contains critical weaknesses, that render all Android wallets generated to date vulnerable to theft. Because the problem lies with Android itself, this problem will affect you if you have a wallet generated by any Android app. An incomplete list would be Bitcoin Wallet, blockchain.info wallet, BitcoinSpinner and Mycelium Wallet.

as a former Google employee I thank you for your vigilance!

[millsdmb]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

http://bitcoin.org/en/alert/2013-08-11-android

We recently learned that a component of Android responsible for generating secure random numbers contains critical weaknesses, that render all Android wallets generated to date vulnerable to theft. Because the problem lies with Android itself, this problem will affect you if you have a wallet generated by any Android app. An incomplete list would be Bitcoin Wallet, blockchain.info wallet, BitcoinSpinner and Mycelium Wallet.

as a former Google employee I thank you for your vigilance!

How many BTC you want for that crazy hat they give you?

[grau]

The new bitcoinj release that will be announced shortly has some initial code for BIP32. It's definitely something I want to integrate. It's difficult on mobile devices because they don't have any swapfile, so you can't just use as much memory as you want. You have to define a key window in which money can be received. Coins sent to keys that fall outside that window won't show up which is obviously very problematic. All in all, it's delicate and will require some careful experimentation and testing to make it work.

The BOP android wallet to be released in conjunction with our payment solution uses BIP32.

The mobile uses the next even index of BIP32 as change and odd as next receiver addresses. The server implements a single pass scan using a BIP32 public key, that generates an increasing look ahead window from last seen address on the block chain.

[tgeller]

What about other Android wallets that are derived from Schildbach's code, such as Litecoin-Qt and Feathercoin-Qt??? I assume they have the same vulnerability. Any plans to update those?

[millsdmb]

What about other Android wallets that are derived from Schildbach's code, such as Litecoin-Qt and Feathercoin-Qt??? I assume they have the same vulnerability. Any plans to update those?

no BTC no care.

don't they call Feather Coin "Fork that Coin"??

[tgeller]

@millsdmb, that's not helpful. Your opinion about Litecoin is less important than helping prevent theft, and hope others in this forum will have useful information for the community at large.

[giszmo]

@millsdmb, that's not helpful. Your opinion about Litecoin is less important than helping prevent theft, and hope others in this forum will have useful information for the community at large.

Not all consider all alt coins part of the community and while I consider most alt coins blatant scams and therefore would not bother helping them not loosing their premined coins or whatever, I wouldn't consider the bitcoin community at large responsible for those rare alt coins that are no scams.

[BitPirate]

How are the patches working around the problem?

Are they using a different source of entropy, or are they checking that the two R-values don't collide?

In my mind, best practice would be to do both.

I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.

But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.

As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?

On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?

[westkybitcoins]

i randomly received .15 btc yesterday to one of my android generated addresses.  Why would I randomly get free money?  this never happened to me before, is this related to the flaw?

Potentially different (worrisome) issue.

https://bitcointalk.org/index.php?topic=269231.0

There is the chance that spending that "free money" could result in the private key of that address being exposed.

[emibe]

Thanks for the update.

[molecular]

But that has nothing to do with deterministic wallets. Non deterministic wallets do not require address re-use.

The reason that clients reuse addresses is because random key wallets are unsuitable for general use.

Requiring users to update their backups after every n transactions results in permanently lost funds.

The solution is to implement BIP32.

correct me if I'm wrong... type 2 deterministic wallets pose a danger in themselves: rf one key gets compromised, all of them are. It's possible a user exportet a single key from his electrum wallet and used it in mycelium (for example). It could get compromised by the bad RNG in android and compromise all keys of the wallet.

I'm all for using deterministic wallets and use them myself. I just don't ever export private keys from them.

[molecular]

Ive always thought computers could not generate random numbers.    I once won a large prize buying the last ticket before a lotto draw, computer random number generator was the source though I didnt complain at the time

Nothing can generate a random number. Us included. Only pseudo-random.

So you believe that radioactive decay is deterministic? If so, you are in the minority. Say I have two uranium atoms and one of the decays before the other, what do you think accounts for that?

God ;-). He makes decisions based on discussion with the other gods. It's not random, but based on divine rationality. Just believe me, I talk to the spaghetti monster every day and it never utters random nonsense.

side-note: Oh hey cool. Here's another reason to found the "church of random".

[justusranvier]

It's possible a user exportet a single key from his electrum wallet and used it in mycelium (for example). It could get compromised by the bad RNG in android and compromise all keys of the wallet.

Does Electrum have "watching only" copies of deterministic wallets like Armory does? The attacker would need access to that in order to compromise the entire wallet instead of just the single private key that was exported and then used on a vulnerable client.

I just don't ever export private keys from them.

Private keys are called "private" for a reason, the belief of some people that it's a good idea to share them notwithstanding...

[Snail2]

Thanks for the update.

[phatsphere]

this thread should be closed, and only updated with news reagrding the actual problem. we don't need yet another fee discussion.

also, one should answer the question, if imported vanity addresses are a problem. i would say no, only the possible other addresses where some change might have gone.

[jubalix]

How vulnerable is electrum to the seed issue that android has
particularly on the various OS's

eg

OSX 10.8 +
WIN7 / WIN 8
UBUNTU

etc
etc

does any one even know???

how can we check we are not doing

http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

this?

[molecular]

How vulnerable is electrum to the seed issue that android has
particularly on the various OS's

eg

OSX 10.8 +
WIN7 / WIN 8
UBUNTU

etc
etc

does any one even know???

how can we check we are not doing

http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

this?

you can look at some signatures and check the random numbers. If they're equal, RNG is flawed. If not there is a chance it's not flawed. One could also look at the implementation. Not sure which random generator electrum uses. It's written in python, chances are it falls back to OS-specific native implementation. I'm pretty sure the mobile version doesn't use the android java implementation.

[grau]

The new bitcoinj release that will be announced shortly has some initial code for BIP32. It's definitely something I want to integrate. It's difficult on mobile devices because they don't have any swapfile, so you can't just use as much memory as you want. You have to define a key window in which money can be received. Coins sent to keys that fall outside that window won't show up which is obviously very problematic. All in all, it's delicate and will require some careful experimentation and testing to make it work.

The BOP android wallet to be released in conjunction with our payment solution uses BIP32.

The mobile uses the next even index of BIP32 as change and odd as next receiver addresses. The server implements a single pass scan using a BIP32 public key, that generates an increasing look ahead window from last seen address on the block chain.

I was asked in a PM if that increases the load on the server with every new transaction.

Yes it does, but we have a strategy to reset the effort. Knowing current master key birth time point limits scan as we only have to scan blocks thereafter. Now, the BOP wallet does not directly use the root BIP32 master, but a current master child of that and rolls to a new master child at user's request thereby resetting birth and scan effort. I consider making these rolls mandatory after a threshold use.

[xenog]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

[solex]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Well done!

The Daily Telegraph is claiming it was known about since January. Is this media disinformation?
The source: http://nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

[piotr_n]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Well done!

The Daily Telegraph is claiming it was known about since January. Is this media disinformation?

Depends how you define "it".
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

[willphase]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Well done!

The Daily Telegraph is claiming it was known about since January. Is this media disinformation?

Depends how you define "it".
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

It's always been known that ECDSA with same random number allows private key discovery. It's been known since earlier this year that some hardware wallets were not using decent random numbers, but as far as I know it's only very recently that it was found that Android PRNG also suffered from this issue.

Will

[piotr_n]

as far as I know it's only very recently that it was found that Android PRNG also suffered from this issue.

Then look at this document - published several months ago:
https://bitcointalk.org/index.php?topic=271486.msg2913741#msg2913741
http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations

[jubalix]

Got error 157 'Unknown error code' from NDBCLUSTER

when trying to check sigs on blockchain.info.....

is this deliberate!!!!

while this is sorted out

[piotr_n]

Got error 157 'Unknown error code' from NDBCLUSTER

when trying to check sigs on blockchain.info.....

is this deliberate!!!!

while this is sorted out

blockchain.info has been sort of offline, for over 5 hrs already.

Moreover blockexplorer.com has also been stopped - somewhere yesterday.

[xenog]

I emailed to a journalist from The Register how I discovered that the Android PRNG affected BitcoinJ applications in Android. Here's a copy of the email I sent to the journalist:

I discovered the flaw thanks to a small stash of stolen bitcoins.

It all started with a missed call from a friend at 00:30 on August 5, and a subsequent SMS telling me that he got 0.91 bitcoins stolen from his Android wallet. "Somebody hacked my Android phone" he would repeat. I did not believe this to be likely. He is the most security conscious person I know. Besides, he is a computer scientist and knows the Bitcoin protocol in and out. Android phones are known to be vulnerable, but it's very unlikely that a phone that only ran reputable apps from Google Play got hacked. I thought about Spock, who quoted Arthur Conan Doyle: "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth". The impossible was that his phone got hacked. The truth then should be that somebody found his private key through cryptanalysis on the Bitcoin blockchain (the public ledger were all transactions are kept).

A lookup on the address that the funds were sent to revealed a forum post https://bitcointalk.org/index.php?topic=251743, so I put on my detective hat and read the post. I also published a message to it stating what had happened to my friend. The common factor seemed to be Android, and I immediately thought about the possibility of a flaw in its pseudo-random number generator (PRNG).

I investigated online and found this paper http://www.scribd.com/doc/131955288/Randomly-Failed-The-State-of-Randomness-in-Current-Java-Implementations#page=9, which I sent to Mike Hearn pointing him to page 9 in which the flaw in Apache Harmony's PRNG (the one used by Android) was described. I also pointed to him that his BitcoinJ code was using that PRNG in the regular non-seeded way, which triggered the flaw.

I originally suggested that private key collisions may have being found and exploited. Later on the weekend a reply to the Bitcoin forum post by johoe clarified that the issue with the PRNG was leading to collisions in the random number parameter k that the elliptic curve signature algorithm needs in order to be secure, making it trivial to extract the private key from two transactions that used the same k.

[gmaxwell]

The Daily Telegraph is claiming it was known about since January. Is this media disinformation?

I'm not sure it thats entirely inaccurate, go look at the bitcoin-dev logs from January. IIRC, there was reason to suspect that some of the duplicate nonce signatures were coming from BitcoinJ and there was some speculation about broken java RNGs that went nowhere.

[narayan]

What do I do?? I have 20 BTC in Blockchain.info and now it doesn't even load

Did someone steal my coins??

Got error 157 'Unknown error code' from NDBCLUSTER

[jubalix]

Got error 157 'Unknown error code' from NDBCLUSTER

when trying to check sigs on blockchain.info.....

is this deliberate!!!!

while this is sorted out

blockchain.info has been sort of offline, for over 5 hrs already.

Moreover blockexplorer.com has also been stopped - somewhere yesterday.

hmm deliberate


but surley bitcoind can do this as well. a program tha compares sigs must be able to run through and auto check

[🏰 TradeFortress 🏰]

Got error 157 'Unknown error code' from NDBCLUSTER

when trying to check sigs on blockchain.info.....

is this deliberate!!!!

while this is sorted out

blockchain.info has been sort of offline, for over 5 hrs already.

Moreover blockexplorer.com has also been stopped - somewhere yesterday.

hmm deliberate


but surley bitcoind can do this as well. a program tha compares sigs must be able to run through and auto check

You should have been emailed a copy of your wallet every time you made changes to it. Import it to Multibit with your passphrase.

[theDF]

What do I do?? I have 20 BTC in Blockchain.info and now it doesn't even load

Did someone steal my coins??

Got error 157 'Unknown error code' from NDBCLUSTER

Calm down, and check you wallet right now because blockchain.info already back to normal *so far

[Mike Hearn]

It's got nothing to do with bitcoinj. The issue is with SecureRandom itself. As far as I know all Bitcoin signing implementations on Android use this API.

[becoin]

done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.

You're joking, aren't you?

This post is over one month old, while this one over half a year...
Watchfulness my ass

As always, Bitcoin is mercilessly exposing every shady practice on everything it touches. I don't trust Google. Like MS they are also in bed with the US government. They try to promote Android as open source but keep the JVM for Android closed. This is why every Java based app for Android is not truly open sourced! Period. Paragraph.

[Predictious]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Well done guys! It would have been fair that Mike Hearn gave you credits.

[molecular]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Thank you so much for your prudence!

[westkybitcoins]

done and done, thanks to you and this community for such watchfulness and timeliness with these kinds of issues.

You're joking, aren't you?

This post is over one month old, while this one over half a year...
Watchfulness my ass

As always, Bitcoin is mercilessly exposing every shady practice on everything it touches. I don't trust Google. Like MS they are also in bed with the US government. They try to promote Android as open source but keep the JVM for Android closed. This is why every Java based app for Android is not truly open sourced! Period. Paragraph.

Hmph.

I think if this were common knowledge it might raise a few eyebrows. I was under the impression it was open-source through and through.

*re-investigates cyanogenmod*

[molecular]

I just remembered: There was a "workshop" at CCC end of last year I attended. Transactions were shown in the blockchain with identical R in signatures. The source was supposedly traced to "bitcoincard" test transactions.

Now I'm not so sure it was the only source.

[westkybitcoins]

also, one should answer the question, if imported vanity addresses are a problem. i would say no, only the possible other addresses where some change might have gone.

Yes, they are.

This particular problem isn't about the private keys themselves (although I wouldn't trust private keys generated with a broken psuedo-random number generator anyway.) The problem is that securely signing a transaction requires using a unique random value each time. If you use the same private key in two different transactions/spends, and this includes vanity addresses, but the same random value is involved in the signing process both times, then your key is compromised.

It doesn't matter what the private key is. If you can't get decent random values to use for the signing, you're going to be exposed. It's a pretty disturbing oversight on the part of those who wrote the Android PRNG library.

[phatsphere]

It's a pretty disturbing oversight on the part of those who wrote the Android PRNG library.

yes. that's what's baffling me, too. especially given the fact, that an android device has much more sources of random information than a commodity pc. just think about gyroscope, magnetism, acceleration, ...

[theDF]

yes. that's what's baffling me, too. especially given the fact, that an android device has much more sources of random information than a commodity pc. just think about gyroscope, magnetism, acceleration, ...

Oh yeah, why the developers never think about it.. using sensors as random generator that almost impossible to generate same pattern, brilliant!

[piotr_n]

Oh yeah, why the developers never think about it.. using sensors as random generator that almost impossible to generate same pattern, brilliant!

Because this should be a duty of an OS, to get adventage of whatever entropy sources it has and provide the apps with an API for a secured random numbers.
At least a modern OS - nobody had expected it from MS-DOS back then

[Mike Hearn]

I already updated the second post after my announcement to give some credit to Jean-Pierre, though I guess most of the credit goes to the researchers who uncovered the vulnerabilities in the first place. But still, it was very useful for Jean-Pierre to inform us privately.

The Android JVM is open source. It's called Dalvik. I don't know where anyone would get the idea it's not open source from.

[HBBZ]

This is a sign of a healthy community. Bravo!

[phatsphere]

Oh yeah, why the developers never think about it..

well, "java" in general has the idea that you do not have to think about this. as a developer you assume that it works – which in reverse is a good way to shoot yourself in the foot. in that case, the implementation of java is the problem. i don't know any details about google's modifications on the underlying linux itself, but my guess is, that it's random number source is also a good one. it's more or less just this broken link between low level to a higher levels which causes this.
if the android linux-os developers are as smart as i think, they're already using all available input sensors as sources for randomness.

[dserrano5]

BitcoinSpinner / Mycelium Wallet

An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.

I just removed Spinner and installed Mycelium. It reports version 0.7.0 beta, is this one safe regarding this problem?

[Diapolo]

It would be nice, it other App stores would also get updates. F-Droid for example doesn't yet show an update for Bitcoin Wallet.

Dia

[niko]

How are the patches working around the problem?

Are they using a different source of entropy, or are they checking that the two R-values don't collide?

In my mind, best practice would be to do both.

I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.

But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.

As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?

On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?

Any comments from the developers here?  Checking the uniqueness would require storing past r values along with the private key. Any problematic consequences of this?

And yes, I am surprised that there is not much buzz about the broken android PRNG in general, unrelated to Bitcoin. Does all crypto on Android rely on this broken PRNG?  Who wrote this particular implementation, who let it slip by? What else has slipped by? 

[apetersson]

BitcoinSpinner / Mycelium Wallet

An update has been prepared for Mycelium Wallet and is being pushed out via the Play Store. If you use BitcoinSpinner you are encouraged to upgrade to Mycelium Wallet, which is maintained by the same people.

I just removed Spinner and installed Mycelium. It reports version 0.7.0 beta, is this one safe regarding this problem?

yes it is. it also features a migration wizard if you generated a key inside Mycelium prior to 0.6.5.

[piotr_n]

How are the patches working around the problem?

Are they using a different source of entropy, or are they checking that the two R-values don't collide?

In my mind, best practice would be to do both.

I see a lot of cases in code where people need multiple random and unique values, (e.g. UUIDs)... where the only two requirements are that they are indeterminate and unique... but because the domain of random outcomes is so huge they rely on the vanishingly small probability of collision, and don't bother to check uniqueness.

But as we have found, that "vanishingly small probability" isn't so small if the PRNG is broken. A simple collision check isn't a waste of CPU cycles -- it guards against this kind of system problem.

As such, can all Bitcoin clients, Android or otherwise, be updated to check that the two R-values are unique?

On a different note, I don't see much discussion about the broken Android PRNG, does anyone have a link to the bug reports? This must have some pretty far-reaching consequences outside Bitcoinland too...?

Any comments from the developers here?  Checking the uniqueness would require storing past r values along with the private key. Any problematic consequences of this?

And yes, I am surprised that there is not much buzz about the broken android PRNG in general, unrelated to Bitcoin. Does all crypto on Android rely on this broken PRNG?  Who wrote this particular implementation, who let it slip by? What else has slipped by? 

AFAIK, the patches are using /dev/random as the source of random data. This one has not been screwed up by Google and it seems to be reliable.

No need to keep track of all previews R values, since a chance of picking up the same 256 bit random number again is likely lower than a chance of the h/w failing in a away that it would broadcast such a stored R values from your history buffer.

And yes - all the other Android apps that rely on SecureRandom class are at risk.
I'm also surprised that Google does not give a shit, since it seems that they have known about this specific issue for months.
Maybe someone should sue them, to teach them a lesson.
I bet that there are plenty of (e.g. online banking) apps that are also affected.

[TippingPoint]

Exhibit A

https://developer.android.com/reference/java/security/SecureRandom.html

[blockgenesis]

I discovered this flaw and made it known to Mike Hearn, Andreas Schildbach and Ben Reeves. It's been quite a week.

Very much appreciated, thanks. And thanks to every developers who worked to push updates and instructions in a very short delay.

[grau]

Exhibit A

https://developer.android.com/reference/java/security/SecureRandom.html

So Google discourages seeding SecureRandom .... Why ?
Maybe the default implementation is NSA approved.

[gmaxwell]

IIRC if you seed it before ever pulling a random number from it, it will only be seeded from your (quite likely weak) seed, and not the OS provided randomness. Seeding it should be unnecessary, and it makes it easy to screw yourself.

[piotr_n]

So Google discourages seeding SecureRandom .... Why ?
Maybe the default implementation is NSA approved.

Hehe - as a guy with a "tinfoil hat" label given already, I must say that it is not an entirely unreasonable theory

[TippingPoint]

Seed PRNG with accelerometer, gyroscope, compass, barometer, or GPS if available?
http://www.gsmarena.com/glossary.php3?term=sensors

[piotr_n]

Seed with accelerometer, gyroscope, compass, barometer, or GPS if available?

But that is exactly what the default OS implementation should be doing.
Instead its seeding with a 31 bit value...

[grau]

IIRC if you seed it before ever pulling a random number from it, it will only be seeded from your (quite likely weak) seed, and not the OS provided randomness. Seeding it should be unnecessary, and it makes it easy to screw yourself.

Understood.

If however the "self seeding" of SecureRandom creates low entropy then it creates a master key to all cryptography used on the device including https://, SSL and not only Bitcoin.

The fact that the few Bitcoin transactions that Android Wallet user created was able to expose the weakness tells me that the flaw is serious to such and extent that I ask if it is intentional.

Edit: I mean a back door with "master key" above. Brute forcing all protocols does not require real force in absence of quality randomness.

[TippingPoint]

"law enforcement remains in unanimous agreement that the continued widespread availability and increasing use of strong, non-recoverable encryption products will soon nullify our effective use of court-authorized electronic surveillance."  _{- Louis Freeh, former Director of FBI}

[becoin]

I already updated the second post after my announcement to give some credit to Jean-Pierre, though I guess most of the credit goes to the researchers who uncovered the vulnerabilities in the first place. But still, it was very useful for Jean-Pierre to inform us privately.

The Android JVM is open source. It's called Dalvik. I don't know where anyone would get the idea it's not open source from.

It's a pseudo open source!

It is not strictly a JVM as it is register based VM (opposed to stack based standard JVM) that executes its own Dalvik byte code, not Java byte code. A tool called dx is used to transform some Java classes into special .dex file format. Some structures (magic numbers) of the .dex file format are not well documented. If you create your own VM and file system and tag it open source you have to open source all the tools you use to compile it including the JIT compiler and interpreter.

Few links exposing recent security holes in Dalvik's proprietary .dex file format:
http://www.retrodev.com/android/dexformat.html

Anatomy of a security hole - Google's "Android Master Key" debacle explained
http://nakedsecurity.sophos.com/2013/07/10/anatomy-of-a-security-hole-googles-android-master-key-debacle-explained/

Anatomy of another Android hole
http://www.digitalnewsasia.com/node/2940

[SgtSpike]

Could the OP be updated to include a list of apps that have been updated against this bug?  I don't want to read through the whole 8 pages to find out which apps have and have not been updated, and I'm sure it'd be helpful to other people as well.

[DiamondCardz]

Could the OP be updated to include a list of apps that have been updated against this bug?  I don't want to read through the whole 8 pages to find out which apps have and have not been updated, and I'm sure it'd be helpful to other people as well.

These are the current statuses:



From http://bitcoin.org/en/alert/2013-08-11-android - they should be getting updated daily.

[phatsphere]

another question i have in mind is chrome, firefox, opera mobile or the native android web browser itself. suppose, i'm using one of those on my android phone or tablet, and i'm using a web-wallet like blockchain or a bitaddress generator. do these browsers also rely on this flaw in java or do they circumvent this via native C code?
i think it depends on the browser …

[CurbsideProphet]

Thanks for the heads up.  Guess I'll have to do another vanity addy, although I've never really used it other than for novelty.

[blockgenesis]

Could the OP be updated to include a list of apps that have been updated against this bug?  I don't want to read through the whole 8 pages to find out which apps have and have not been updated, and I'm sure it'd be helpful to other people as well.

These are the current statuses:



From http://bitcoin.org/en/alert/2013-08-11-android - they should be getting updated daily.

Blockchain.info just released v3.54 , I've updated the page, it should refresh in the next minutes. Afterwhile, perhaps that few more details will be added but since all stated wallets now have updates published, I guess that most of it is over. Now it's just a matter of waiting for these updates to deploy and stay around to see how it goes.

[Hawkix]

Shouldn't the key rotation be performed only on private keys known to be influenced (generation, transaction signatures) by this random generator flaw? I do not want to run Blockchain on my Android to realize that it will re-send and merge (automatically .. ugh) all my savings into another address!

[apetersson]

another question i have in mind is chrome, firefox, opera mobile or the native android web browser itself. suppose, i'm using one of those on my android phone or tablet, and i'm using a web-wallet like blockchain or a bitaddress generator. do these browsers also rely on this flaw in java or do they circumvent this via native C code?
i think it depends on the browser …

nobody knows. auditing this piece of code is very complex.

just think about why some TLAs were boasting about "phenomenal breakthroughs" in cryptanalysis.
http://www.wired.com/threatlevel/2012/03/ff_nsadatacenter/all/1

a few months ago most of this speculation was conspiracy theory. now some of this is conspiracy fact.
seeing this kind of code audit failure/randomness failure makes me go shopping for tinfoil hats.

on my back-of the-spreadsheet envelope calculation i have estimated the "real" keyspace of SecureRandom to be very, very low.
definitely not 2^256.
edit: i don't even dare to write the number down - if the calculation is right this is too scary.

https://docs.google.com/spreadsheet/ccc?key=0Av2s7TgXTjFTdDNNZUlrb1ZPUG9EYmZGV0drZ1dWVlE#gid=0
this calculation is based on the fact that we have seen at least 1 collision of random values on android phones.
last time i did statistics was 10 years ago, so please point out any errors.

it also points out a discrepancy. if the entropy would be that low, we would see a massive amount of duplicate addresses. which are absent. i suspect the private key space is large enough - but the entropy provided at signing is too low.

[ThomasV]

Just wondering, would this affect Electrum as well?

http://electrum.org/android.html

From what we can gather, this issue seems to be a Java PRNG implementation issue.
Electrum should be safe from this, because it does not use Java; it uses /dev/urandom directly.
However, there might be other bugs in the Android platform, which is under overall scrutiny following this issue.

[Lauda]

Fixed?

[CurbsideProphet]

Shouldn't the key rotation be performed only on private keys known to be influenced (generation, transaction signatures) by this random generator flaw? I do not want to run Blockchain on my Android to realize that it will re-send and merge (automatically .. ugh) all my savings into another address!

This is why it's better to have your savings in an offline/paper wallet.  Use blockchain only for the Bitcoins you're going to be using for near-term transactions.

[dwolfman]

Could the OP be updated to include a list of apps that have been updated against this bug?  I don't want to read through the whole 8 pages to find out which apps have and have not been updated, and I'm sure it'd be helpful to other people as well.

These are the current statuses:



From http://bitcoin.org/en/alert/2013-08-11-android - they should be getting updated daily.

I'm wondering if this means they aren't updating Bitcoin Spinner?  Got my phone set up the way I want it, and this means switching yet another app out.  I don't have any bitcoins in it right now, and probably won't in the near future anyway.  Haven't sent anything from it in months, so I'm not in too big a hurry to update it.

[Kiwi7]

Whoa whoa, I've just transferred all my BTC from an Android wallet to inputs.io.

[apetersson]

I'm wondering if this means they aren't updating Bitcoin Spinner?  Got my phone set up the way I want it, and this means switching yet another app out.  I don't have any bitcoins in it right now, and probably won't in the near future anyway.  Haven't sent anything from it in months, so I'm not in too big a hurry to update it.

According to Jan, an update to bitcoinspinner was pushed to google play, will appear soon.

[Roy Badami]

This post http://seclists.org/oss-sec/2013/q3/358 mentions deterministic ECDSA signatures and references RFC 6979.

Is there any reason why Bitcoin clients shouldn't use this construction, other than perhaps the possible newness of this exact instantiation?

roy

[Mike Hearn]

That RFC was published only a few days ago. To call it "new" would be an understatement.

IMO it doesn't make much difference. We could implement it, but it would not have avoided the need to do a key rotation.

[millsdmb]

just got the new wallet app pushed out to my phone, so everyone should have it available by now if you include the links posted a few replies up.

[frankenmint]

what do i do if my wallet address is locked onto another site and I've updated my wallet already? will it go to the old address then be transferred internally into the new one?

[blockgenesis]

I'm wondering if this means they aren't updating Bitcoin Spinner?  Got my phone set up the way I want it, and this means switching yet another app out.  I don't have any bitcoins in it right now, and probably won't in the near future anyway.  Haven't sent anything from it in months, so I'm not in too big a hurry to update it.

According to Jan, an update to bitcoinspinner was pushed to google play, will appear soon.

It seems that the update for BitcoinSpinner is pushed to Google Play now according to the version history. I've emailed Jan to ask him to provide short instruction text to be published on bitcoin.org .

[frankenmint]

BTCy the way, my import/export keys menu options are greyed out.  What do I do?  How can I get my BTC?

[rampantparanoia]

what do i do if my wallet address is locked onto another site and I've updated my wallet already? will it go to the old address then be transferred internally into the new one?

no, you need to change the address on the other site.
bitcoin protocol does not link addresses like this

thanks for the announcement & making the community aware. extra thanks to the person who found this flaw

[Mike Hearn]

actually he is right. Coins received to old insecure addresses will be automatically resent to the new address when it confirms.

[Paladin69]

The blockchain.info wallet doesn't work if you have a secondary password so long that it needs to be pasted in.  Holding your finger on it to paste flashes the field box away.

[Hawkix]

Anyone already tested blockchain.info Android wallet with "automatic key rotation"? Is the user possible to skip that step?

[Kiwi7]

BTCy the way, my import/export keys menu options are greyed out.  What do I do?  How can I get my BTC?

Transfer all your BTC to an online BTCitcoin wallet, like Inputs.io or BTClockchain.info.

[casascius]

When I made my key generator for Casascius Coins, I started with the assumption that the secure random number generator could not fully be trusted.  I did it on Windows not Android so it's not at risk, but the paranoid idea I tried would have completely eliminated this problem had it been done in these wallets.

Instead of accepting the output of secure random as truly securely random, I just considered it a "good source of entropy" and XOR'd its output with another lukewarm but "extra" source of entropy: a hash of a string that gets the current time appended to it whenever the user does something (moves mouse, presses a button, etc).  Also included in the hash is a counter that increments each time entropy is read so it can never be the same twice.  (When the string grows too big, it is replaced by a hash of itself)

For my actual coin generation process, I ask the user (myself) for a third string of input: something that will also be included in the hash.  Each time, I mash the keyboard for a line or two of text e.g. weiajeflkjf;iefw;fiowjR[2348RU20389U0R9EWAEO;FIJSDF;KJVNXVDFJKG;lkdjfgosidfjaiwe --- and never record the string.

None of these methods would be "great" by themselves, but by xoring the output of all of them together, I feel well hedged against the possibility of crappy RNG's.

[phatsphere]

@casascius: do you know about this page: http://www.random.org/bytes/ ? that could also be a source, which could replace the mouse-moving-timestamp thing because it comes from an external source.

[casascius]

@casascius: do you know about this page: http://www.random.org/bytes/ ? that could also be a source, which could replace the mouse-moving-timestamp thing because it comes from an external source.

Sure, though I have every reason to believe their bytes are truly random, for security purposes, I don't.  When I generate keys, the machine doesn't have internet access anyway, so I suppose it's just an alternative (sub)string to paste as a response to the "keyboard mash" if I want to copy it in with a flash drive etc.

[niko]

What casascius described sounds good. XORing even with a constant will certainly not decrease entropy. Thus, his method can only make things better.

[niko]

How was SecureRandom seeding implemented in vulnerable wallets? Was it custom-seeded, or left as default?

EDIT - never mind. The problem was not with the implementation in wallet software, but was and still is with Android.
http://www.nds.rub.de/media/nds/veroeffentlichungen/2013/03/25/paper_2.pdf

When creating a self seeding SecureRandom instance (by calling the constructor without arguments and subsequent setSeed() call), the code fails to adjust the byte offset (a pointer into the state buffer) after inserting a start value. This causes a counter and the beginning of a padding (a 32 bit word) to overwrite parts of the seed instead of appending.

[Huangww]

very quick。

[qwk]

@casascius: do you know about this page: http://www.random.org/bytes/ ? that could also be a source, which could replace the mouse-moving-timestamp thing because it comes from an external source.

Sure, though I have every reason to believe their bytes are truly random, for security purposes, I don't.  When I generate keys, the machine doesn't have internet access anyway, so I suppose it's just an alternative (sub)string to paste as a response to the "keyboard mash" if I want to copy it in with a flash drive etc.

Shouldn't it be possible to just use the hardware RNG from a Raspberry Pi to just create a bunch of addresses?
Could be less painful than hammering your keyboard repetitively ;-)

[TippingPoint]

I like the generate random seed method that KeePass (free and open source) uses.  Your choice of mouse movement and/or keyboard gibberish.



KeePass needs to generate several random bytes (for the IV, the master key salt, etc.). For this, several pseudo-random sources are used: current tick count, performance counter, system date/time, mouse cursor position, memory status (free virtual memory, etc.), active window, clipboard owner, various process and thread IDs, various window handles (active window, desktop, ...), window message stack, process heap status, process startup information and several system information structures. Additionally, KeePass uses random bytes provided by the system's default CSP RNG.

This pseudo-random data is collected in a random pool. To generate 16 random bytes, the pool is hashed (SHA-256) with a counter. The counter is increased after 16 generated bytes. This way, as many secure random bytes can be produced efficiently as needed.

[gbl08ma]

I have the blockchain.info app installed on my Android device, but I am sure that I never created a new address within it and I'm also sure that I never created a transaction on that device. Basically the app only acted as a way to check the wallet balance and transaction history (i.e. read-only actions).

Are my private keys and transactions at risk if I don't do a key rotation? With the many small and non-mature inputs I have on my many addresses, I am heading for maybe over 0.02 btc for transaction fees... last time I did a key sweep it was something like 0.01 btc, and to be honest I think my wallet is even more fragmented now.

I don't think the app ever had any reason to request random numbers unless it is creating addresses without user intervention.

On a related thought: many online wallets generate private keys client side with JavaScript. How secure is the PRNG used by JS, or is it not used in a direct way (are there other sources of entropy)?

[Lauda]

very quick。

It would be a huge problem if it wasn't quick enough.

[SgtSpike]

I have the blockchain.info app installed on my Android device, but I am sure that I never created a new address within it and I'm also sure that I never created a transaction on that device. Basically the app only acted as a way to check the wallet balance and transaction history (i.e. read-only actions).

Are my private keys and transactions at risk if I don't do a key rotation? With the many small and non-mature inputs I have on my many addresses, I am heading for maybe over 0.02 btc for transaction fees... last time I did a key sweep it was something like 0.01 btc, and to be honest I think my wallet is even more fragmented now.

I don't think the app ever had any reason to request random numbers unless it is creating addresses without user intervention.

On a related thought: many online wallets generate private keys client side with JavaScript. How secure is the PRNG used by JS, or is it not used in a direct way (are there other sources of entropy)?

My understanding is that if you sent Bitcoins from any of the addresses in your blockchain.info wallet more than once, it could reveal the private key of said addresses to anyone clever enough looking at the blockchain.  If you didn't generate any addresses or send any Bitcoins from it, then you should be fine.

[apetersson]

My understanding is that if you sent Bitcoins from any of the addresses in your blockchain.info wallet more than once, it could reveal the private key of said addresses to anyone clever enough looking at the blockchain.  If you didn't generate any addresses or send any Bitcoins from it, then you should be fine.

If you did reveal your private key that way, your money should already be gone. if it is not gone its a pretty good indication that everything is fine

[Emm]

Did anyone get their mobile wallet BTC stolen?

[b!z]

Did anyone get their mobile wallet BTC stolen?

Yes, https://gist.github.com/anonymous/6204930

[niko]

Did anyone get their mobile wallet BTC stolen?

Yes. A total of 55 coins so far. https://bitcointalk.org/index.php?topic=271486.0

The relatively small amount is partly due to quick response of the community, and partly due to the fact that Android bug does not lead to every transaction being exploitable. Still, the bug has been public for many months now. Everyone - from obviously overpaid Google developers, to obviously underpaid Bitcoin developers, should be even more careful moving forward from here. This flaw was not catastrophic, but the next one may be. Tread carefully.

[wopwop]

pseudo random number generation used in security systems is nothing more than *security through obscurity*

[Tommy76]

very quick。

It would be a huge problem if it wasn't quick enough.

So, I think it's a huge problem, check the date of this post:
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

[Mike Hearn]

That post is unrelated to issues on Android.

[Jan]

very quick。

It would be a huge problem if it wasn't quick enough.

So, I think it's a huge problem, check the date of this post:
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

What this blog post doesn't tell is that in this particular instance the repeated use of the same K value was on purpose.
When making unit tests it is often desirable to be able to create results that can be repeated. By reusing the same K value you get the same signature, which is valuable during development. I know the developer in for this instance, and no, it is not me.

[niko]

very quick。

It would be a huge problem if it wasn't quick enough.

So, I think it's a huge problem, check the date of this post:
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

That post is unrelated to issues on Android.

It definitely is related to the exploit. And this one is also related, and was presented to the public almost half a year ago. Granted, it appears that android securerandom is broken beyond what is described in the RSA 2013 paper.

[ReCat]

@casascius: do you know about this page: http://www.random.org/bytes/ ? that could also be a source, which could replace the mouse-moving-timestamp thing because it comes from an external source.

Sure, though I have every reason to believe their bytes are truly random, for security purposes, I don't.  When I generate keys, the machine doesn't have internet access anyway, so I suppose it's just an alternative (sub)string to paste as a response to the "keyboard mash" if I want to copy it in with a flash drive etc.

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

[molecular]

very quick。

It would be a huge problem if it wasn't quick enough.

So, I think it's a huge problem, check the date of this post:
http://www.nilsschneider.net/2013/01/28/recovering-bitcoin-private-keys.html

This was known for even longer. The news was discovery of weakness in apache harmony RNG used by android.

[niko]

@casascius: do you know about this page: http://www.random.org/bytes/ ? that could also be a source, which could replace the mouse-moving-timestamp thing because it comes from an external source.

Sure, though I have every reason to believe their bytes are truly random, for security purposes, I don't.  When I generate keys, the machine doesn't have internet access anyway, so I suppose it's just an alternative (sub)string to paste as a response to the "keyboard mash" if I want to copy it in with a flash drive etc.

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

You may be missing the point here. There is more than enough entropy available in a phone or a PC. The problem is with human errors when coding and otherwise implementing the RNG. In this case, lazy Google employees who copy-pasted broken Apache code without reviewing it, and didn't even bother fixing it or rewriting the documentation when some of the flaws were made public half a year ago.
Building your own hardware, by yourself, will likely lead to more errors.

[casascius]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

[phatsphere]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

instead of *radio*active material, you can use *radio*waves. just tune in a lower kHz frequency where a lot of noise from the earth's atmosphere is audible. that's one of the sources providers like random.org use. i guess it's pretty easy to get this running and then pulling the bytes from the A/D converter of your soundcard.

[justusranvier]

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

Pick up some banana from the grocery store next time.

[P_Shep]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

dismantle a smoke detector

[stereotype]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

dismantle a smoke detector

Or a bowl of brazil nuts

[ralree]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

Actually, you can just push a transistor into avalanche - it only take a few discrete components:

http://holdenc.altervista.org/avalanche/

[TippingPoint]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

dismantle a smoke detector

Or a bowl of brazil nuts

Formerly known as ...

[Lauda]

dismantle a smoke detector

Or a bowl of brazil nuts

Formerly known as ...

the hero of?

[niko]

dismantle a smoke detector

Or a bowl of brazil nuts

Formerly known as ...

the hero of?

Quit generating randomness, and get back to the topic. I read in the news that Google has acknowledged the problem, and recommends developers use dev/(u)rand. Good luck patching Android with third parties between Google and your phone.

[justusranvier]

Good luck patching Android with third parties between Google and your phone.

It bet Cyanogenmod users get access to the patches first.

[allbiznessman]

So, does this only affect Android wallets (Private Keys) generated by the Android wallet apps, or would my BTC address which I already had and then added to the blockchain wallet app also be affected? I hope not, cause I like keeping the same address for Public use, and then moving the BTC into my private addresses, never revealing public keys or addresses.

[Rannasha]

So, does this only affect Android wallets (Private Keys) generated by the Android wallet apps, or would my BTC address which I already had and then added to the blockchain wallet app also be affected? I hope not, cause I like keeping the same address for Public use, and then moving the BTC into my private addresses, never revealing public keys or addresses.

It only affects addresses/keys that are generated on Android.

[Carlton Banks]

You should make your own hardware for pulling random data for your coins. Something like a geiger counter near a radiation source. Now that would be truly the best source for truly random data.

(Unless if you distrust the laws of physics  )

I would have, but at the time, I was fresh out of radioactive material. Maybe next time.

Lol, how long before the FBI kicks your door in? Didn't everyone get the memo that making online jokes about possessing WMD's are indistinguishable from sincere admissions? 

[niko]

So, does this only affect Android wallets (Private Keys) generated by the Android wallet apps, or would my BTC address which I already had and then added to the blockchain wallet app also be affected? I hope not, cause I like keeping the same address for Public use, and then moving the BTC into my private addresses, never revealing public keys or addresses.

It only affects addresses/keys that are generated on Android.

This is incorrect. The problem also affects imported keys if they were ever used to send funds from an android client.

[Gator-hex]

a component of Android responsible for generating secure random numbers contains critical weaknesses

or did someone just forget to seed it properly?

"Everytime I give a seed and try to generate 100 numbers, they all are the same. Please help."
http://stackoverflow.com/questions/12458383/java-random-numbers-using-a-seed

 

[BurtW]

a component of Android responsible for generating secure random numbers contains critical weaknesses

or did someone just forget to seed it properly?

"Everytime I give a seed and try to generate 100 numbers, they all are the same. Please help."
http://stackoverflow.com/questions/12458383/java-random-numbers-using-a-seed

 

The referenced posting is unrelated.  It concerns a person not understanding the Random() function and the fact that every time you use the same seed for that function you get the same sequence.

They are using Random() we are discussing SecureRandom(), two different functions.

However, as far as I can tell the problem with the SecureRandom() function did have to do with seeding, it is just not the same seeding issue discussed in the link.

[molecular]

Let's talk bitcoin episode about the issue. http://www.youtube.com/watch?v=4zTocJflyS8

Contains interesting interview with Andreas Pettersen ((co-)author of mycelium wallet)

Apparently under certain circumstances (some fallbacks) the entropy of the android RNG drops to just 9 bits.

Did anyone find more information about what exactly is going wrong?

[casascius]

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

The "some_user_supplied_constant" could be nothing more than a string collected from the user upon first invocation of the program, and perhaps even saved to a config file.  It serves the same purpose as salt.  Because the user supplies it, it's pretty easy to verify that it isn't predictable.  It will have relatively poor entropy, but would successfully serve the purpose of making mass cracking of insecure random numbers pretty much impossible, as well as verifiably ensuring that there is some portion of the input that is truly unpredictable by an outside attacker.

[TippingPoint]

Listen to him ^  ^

[justusranvier]

...or use BIP32 to generate the addresses.

[weavejester]

A quick question. Is there any way of getting to the rotated keys of the Bitcoin Android app from a backup of the old keys? Or is there any auto-backup facility for the application? Or an auto-backup after the key rotation?

From a look on blockchain.info, it looks like the Android bitcoin wallet generated a new key and transferred all of my existing bitcoins across to the new address without any user intervention. However, the application cache for the bitcoin app has been cleared, so it doesn't appear to have the private key to the new address.

Please tell me that the update didn't automatically transfer all the bitcoins over to a new address without making some form of backup first? It definitely looks like that's the case, but it's such an obviously terrible idea that I have difficulty believing anyone could have actually done it without some form of safeguard.

[TheKoziTwo]

"apetersson" says that "nobody knows" if bitaddress.org is safe... but even in the worst case scenario that there is a problem with the random algorithm wouldn't the entropy by mouse movement requirement be enough to ensure keys are still random?

I don't see how it can not be safe... thoughts?

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

The "some_user_supplied_constant" could be nothing more than a string collected from the user upon first invocation of the program, and perhaps even saved to a config file.  It serves the same purpose as salt.  Because the user supplies it, it's pretty easy to verify that it isn't predictable.  It will have relatively poor entropy, but would successfully serve the purpose of making mass cracking of insecure random numbers pretty much impossible, as well as verifiably ensuring that there is some portion of the input that is truly unpredictable by an outside attacker.

This user supplied constant is the same as the mouse entropy used at bitaddress right?

[casascius]

This user supplied constant is the same as the mouse entropy used at bitaddress right?

Sort of.  A keyboard mash is much easier to audit that it's properly being added to the entropy pool.  If I can verify that the generator is producing private keys that are a hash of my chosen string plus some other data, I think it's fair game to assume that if my string is decently unpredictable and secret, that my private keys aren't going to be predictable to an outside guessing attack.  The problem with mouse data is it's hard to know if it was any good.  What if the user has a touchscreen and doesn't generate mouse movement events unless you actually press something etc...?  Bitaddress.org moves on with whatever additional entropy it presumably got from the mouse, which could be zero, and which someone might later find it may dangerously be not enough.

I think keyboard mashes have low entropy per character (e.g. I bet "asdf" is quite overrepresented in them) but if they're forced to be very long (like a line or two of text) I see them as a very decent way to "cut" the output of a "securerandom" that might be later found to be broken ("cut" as in cut a deck of cards)

[WinVery.com]

This will never happen as required in full.  Sounds like a job for a mop.

[molecular]

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

My first thought about this idea was: No, an app dev should not concern himself with crypto primitives. The underlying rng used should already do that (combine different sources). Best practice is to leave implementation of primitives to experts and crowd-scrutiny. Obviously this best practice failed.

Seeing that combination of different sources doesn't remove any entropy (this is the case, right?), I changed my mind.

[niko]

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

My first thought about this idea was: No, an app dev should not concern himself with crypto primitives. The underlying rng used should already do that (combine different sources). Best practice is to leave implementation of primitives to experts and crowd-scrutiny. Obviously this best practice failed.

Seeing that combination of different sources doesn't remove any entropy (this is the case, right?), I changed my mind.

I would be more comfortable xoring than concatenating multiple inputs.

[Hawkix]

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

My first thought about this idea was: No, an app dev should not concern himself with crypto primitives. The underlying rng used should already do that (combine different sources). Best practice is to leave implementation of primitives to experts and crowd-scrutiny. Obviously this best practice failed.

Seeing that combination of different sources doesn't remove any entropy (this is the case, right?), I changed my mind.

I would be more comfortable xoring than concatenating multiple inputs.

There's a lot of XORing inside SHA256, do not worry ;-).

[Hawkix]

...

From a look on blockchain.info, it looks like the Android bitcoin wallet generated a new key and transferred all of my existing bitcoins across to the new address without any user intervention. However, the application cache for the bitcoin app has been cleared, so it doesn't appear to have the private key to the new address.

...

Are you telling us that the new BlockChain Android app did this automatically, without asking user?

I've never generated a key or send transaction from my Android app yet, and I do not want to have all my addresses here mixed together and sent to another private address.

Can you describe how this automatic process (SCARY) works, when running updated Blockchain app?

[JoelKatz]

I would be more comfortable xoring than concatenating multiple inputs.

Your better off concatenating and then hashing the concatenation to the needed size. XORing is not a good idea. To see why, consider which of these is safer (where | is concatenation).

1) XOR(SHA256(X), SHA256(X))

2) SHA256(X | X)

The former is zero no matter what X is. The latter is safe so long as X is safe.

Now, consider this. X and Y are fairly random but, due to a broken PRNG, only differ in a few bits. Which is safer:

1) XOR(X, Y)

2) SHA256(X | Y)

The former can be insecure even if both X and Y are secure alone because all the common bits drop out. 2 is at least as strong as the stronger of X alone or Y alone.

[🏰 TradeFortress 🏰]

On certain environments (like Chrome/Firefox with no hardware RNG access through JS), Blockchain.info is susceptible to the same attack (reused R value) outside of Android.

See this thread for more information: https://bitcointalk.org/index.php?topic=277595.0

[Lauda]

Listen to him ^  ^

+1
He is a wise amn.

[weavejester]

...

From a look on blockchain.info, it looks like the Android bitcoin wallet generated a new key and transferred all of my existing bitcoins across to the new address without any user intervention. However, the application cache for the bitcoin app has been cleared, so it doesn't appear to have the private key to the new address.

...

Are you telling us that the new BlockChain Android app did this automatically, without asking user?

I've never generated a key or send transaction from my Android app yet, and I do not want to have all my addresses here mixed together and sent to another private address.

Can you describe how this automatic process (SCARY) works, when running updated Blockchain app?

It was the bitcoin-wallet app I was using. I checked the blockchain.info website to trace the transactions the app took. I've got no idea if the blockchain android app does the same thing as bitcoin-wallet.

[TheKoziTwo]

This user supplied constant is the same as the mouse entropy used at bitaddress right?

Sort of.  A keyboard mash is much easier to audit that it's properly being added to the entropy pool.  If I can verify that the generator is producing private keys that are a hash of my chosen string plus some other data, I think it's fair game to assume that if my string is decently unpredictable and secret, that my private keys aren't going to be predictable to an outside guessing attack.  The problem with mouse data is it's hard to know if it was any good.  What if the user has a touchscreen and doesn't generate mouse movement events unless you actually press something etc...?  Bitaddress.org moves on with whatever additional entropy it presumably got from the mouse, which could be zero, and which someone might later find it may dangerously be not enough.

I think keyboard mashes have low entropy per character (e.g. I bet "asdf" is quite overrepresented in them) but if they're forced to be very long (like a line or two of text) I see them as a very decent way to "cut" the output of a "securerandom" that might be later found to be broken ("cut" as in cut a deck of cards)

Yeah that makes sense. I make sure to move the mouse around as much as possible before generating addresses. But I guess bitaddress could improve here, they could do like TrueCrypt, letting the user move the mouse around for as long as user wants, I usually move the mouse a few minutes when creating a TrueCrypt container. And they could introduce a minimum amount of movement... If they did that, it would be as good as keyboard input I assume.

[molecular]

I would feel much better if bitcoin wallets generated new addresses using the following method:

SHA256(something_from_SecureRandom + some_user_supplied_constant + some_incrementing_counter + current_system_time/tickcount)

My first thought about this idea was: No, an app dev should not concern himself with crypto primitives. The underlying rng used should already do that (combine different sources). Best practice is to leave implementation of primitives to experts and crowd-scrutiny. Obviously this best practice failed.

Seeing that combination of different sources doesn't remove any entropy (this is the case, right?), I changed my mind.

I would be more comfortable xoring than concatenating multiple inputs.

doesn't make much difference if you feed it through sha256 in the end.

[molecular]

I would be more comfortable xoring than concatenating multiple inputs.

Your better off concatenating and then hashing the concatenation to the needed size. XORing is not a good idea. To see why, consider which of these is safer (where | is concatenation).

1) XOR(SHA256(X), SHA256(X))

2) SHA256(X | X)

The former is zero no matter what X is. The latter is safe so long as X is safe.

Now, consider this. X and Y are fairly random but, due to a broken PRNG, only differ in a few bits. Which is safer:

1) XOR(X, Y)

2) SHA256(X | Y)

The former can be insecure even if both X and Y are secure alone because all the common bits drop out. 2 is at least as strong as the stronger of X alone or Y alone.

Thanks for this explanation! Didn't think of that danger with XOR.

niko just made a point towards "app developers should not concern themselves with coding crypotgraphic primitives, not even combining them". I'm trending back to "best left to experts".

[molecular]

This user supplied constant is the same as the mouse entropy used at bitaddress right?

Sort of.  A keyboard mash is much easier to audit that it's properly being added to the entropy pool.  If I can verify that the generator is producing private keys that are a hash of my chosen string plus some other data, I think it's fair game to assume that if my string is decently unpredictable and secret, that my private keys aren't going to be predictable to an outside guessing attack.  The problem with mouse data is it's hard to know if it was any good.  What if the user has a touchscreen and doesn't generate mouse movement events unless you actually press something etc...?  Bitaddress.org moves on with whatever additional entropy it presumably got from the mouse, which could be zero, and which someone might later find it may dangerously be not enough.

I think keyboard mashes have low entropy per character (e.g. I bet "asdf" is quite overrepresented in them) but if they're forced to be very long (like a line or two of text) I see them as a very decent way to "cut" the output of a "securerandom" that might be later found to be broken ("cut" as in cut a deck of cards)

Yeah that makes sense. I make sure to move the mouse around as much as possible before generating addresses. But I guess bitaddress could improve here, they could do like TrueCrypt, letting the user move the mouse around for as long as user wants, I usually move the mouse a few minutes when creating a TrueCrypt container. And they could introduce a minimum amount of movement... If they did that, it would be as good as keyboard input I assume.

The "keyboard mashes" usually work by timing the keystrokes, no?

[casascius]

Thanks for this explanation! Didn't think of that danger with XOR.

niko just made a point towards "app developers should not concern themselves with coding crypotgraphic primitives, not even combining them". I'm trending back to "best left to experts".

The danger with XOR is nonexistent if you're combining entropy from two different sources.  If you are XORing keyboard gibberish with the output of securerandom, the odds of them being identical are for practical purposes zero, unless securerandom becomes suddenly broken in a way that it just happens to return user keyboard input instead of random-looking numbers, which is pretty unlikely.

"Rolling your own crypto" = trying to reinvent AES.

XORing two completely independent sources of likely good random data = simple enough to not be crossing the line of rolling your own crypto, in my opinion.

[casascius]

The "keyboard mashes" usually work by timing the keystrokes, no?

If you can take the timing into account, then sure, that's extra entropy, better than not having it.  But the keystrokes themselves, as biased as they will be toward "asdf" and such, are still going to have at least a couple useful bits of entropy a piece, and importantly, they preserve the ability to positively verify that the string you entered gets passed to the hash function as part of the input string to be hashed.

[niko]

I would be more comfortable xoring than concatenating multiple inputs.

Your better off concatenating and then hashing the concatenation to the needed size. XORing is not a good idea. To see why, consider which of these is safer (where | is concatenation).

1) XOR(SHA256(X), SHA256(X))

2) SHA256(X | X)

The former is zero no matter what X is. The latter is safe so long as X is safe.

Now, consider this. X and Y are fairly random but, due to a broken PRNG, only differ in a few bits. Which is safer:

1) XOR(X, Y)

2) SHA256(X | Y)

The former can be insecure even if both X and Y are secure alone because all the common bits drop out. 2 is at least as strong as the stronger of X alone or Y alone.

I was referring to seeded random generators f(xor(A,B)) versus f(A|B). With an ideal function, it shouldn't matter. With a broken one, it might matter.

[JoelKatz]

I was referring to seeded random generators f(xor(A,B)) versus f(A|B). With an ideal function, it shouldn't matter. With a broken one, it might matter.

With a broken one, you're much better off with f(A|B) than f(xor(A,B)). If A and B have too many bits in common, the xor is a disaster.

[grau]

I was referring to seeded random generators f(xor(A,B)) versus f(A|B). With an ideal function, it shouldn't matter. With a broken one, it might matter.

With a broken one, you're much better off with f(A|B) than f(xor(A,B)). If A and B have too many bits in common, the xor is a disaster.

If the generator is broken no operator will make it better. Feed a shifted pattern to | and see an other sort of disaster.

[JoelKatz]

If the generator is broken no operator will make it better. Feed a shifted pattern to | and see an other sort of disaster.

Agreed, but it's still important to prefer an operator that won't make it worse over one that will.

[grau]

If the generator is broken no operator will make it better. Feed a shifted pattern to | and see an other sort of disaster.

Agreed, but it's still important to prefer an operator that won't make it worse over one that will.

do not get your point. xor is not worse than or since none of them add any value in this context.

[JoelKatz]

do not get your point. xor is not worse than or since none of them add any value in this context.

We are comparing XOR to concatenation. And XOR is much worse. If you XOR two values that have a lot of bits in common, even if each of them is secure individually, the result of the XOR may be predictable, even if you hash it afterwards. If you concatenate, the result is at least as strong as the weakest thing you concatenated, even if you hash it afterwards (up to the strength of the hash function).

[niko]

do not get your point. xor is not worse than or since none of them add any value in this context.

We are comparing XOR to concatenation. And XOR is much worse. If you XOR two values that have a lot of bits in common, even if each of them is secure individually, the result of the XOR may be predictable, even if you hash it afterwards. If you concatenate, the result is at least as strong as the weakest thing you concatenated, even if you hash it afterwards (up to the strength of the hash function).

You have chosen a particular state of brokenness of the two sources of entropy, so they tend to have bits in common, and so that xoring indeed leads to low-entropy seed. I have chosen a particular state of brokenness, so that one of the two sources is broken, the other is not. In that case, xoring will be at least as strong as the stronger source itself (the extreme case of broken source always returning the same number).
Having said all that, I can't remember why I thought concatenation might be worse - I was imagining a broken hash function whose output depends, for example, more on the first half of the input block, and less on the second half. But that still wouldn't help my original claim, since presumably my two inputs are the same size or larger than the block size - definitely not smaller, as that would be a glaring mistake.
Thanks for being patient with this. I've obviously realized a few things in the process, most importantly that amateur cryptography makes as much sense as amateur brain surgery.

[TippingPoint]

More amateur cryptography:

Is there a compound function that could address both examples of brokenness better than either XORed or concatenated seeds alone?

[apetersson]

instead of toying around with XOR and |  you want to feed it in a cryptographic hash function such as sha256 to accumulate the entropy. "simply" feed every new genuine randomness to a MessageDigest
 and read the randomness from it. A proper application of this approach is the Fortuna PRNG. I will dedicate some resources into providing a library for Android + java from it, so we no longer have to trust /dev/urandom exclusively.

[phatsphere]

I will dedicate some resources into providing a library for Android + java from it, so we no longer have to trust /dev/urandom exclusively.

the google opensource/android blog just recently featured a workaround with a code example. have you seen it?

[JoelKatz]

More amateur cryptography:

Is there a compound function that could address both examples of brokenness better than either XORed or concatenated seeds alone?

I don't think there's any defect in using the hash of the concatenated seeds. Of course you have to choose an appropriate hash function, but other than that you should be fine. The output should be at least as strong as the strongest of the seeds you concatenated, up to the strength of the hash function.

[casascius]

You have chosen a particular state of brokenness of the two sources of entropy, so they tend to have bits in common, and so that xoring indeed leads to low-entropy seed. I have chosen a particular state of brokenness, so that one of the two sources is broken, the other is not.

In support of this, in my case, I've suggested that two sources of entropy should be so different such that the possibility of them being broken in the same way is negligible.

(e.g. source #1 = keyboard mash, source #2 = /dev/urandom, and the likelihood of the hash of my keyboard mashing having any coincidence with the output of /dev/urandom being zilch.  The only plausible worst case scenario - which would have to be "/dev/urandom is really just a keylogger that returns the hash of recent keyboard input" is something easily proven to be false to anyone even remotely familiar with how /dev/urandom really works)

If this is done, then XORing and concatenation should be equally effective.

On the other hand, if source #1 and source #2 are similar or the same RNG that is suspected to be broken, then I believe concatenation and XOR to both be ineffective, because both of them are pretending that it's a safe assumption that an RNG found to lack entropy (i.e. is broken) can suddenly be redeemed by running it twice.

[JoelKatz]

In support of this, in my case, I've suggested that two sources of entropy should be so different such that the possibility of them being broken in the same way is negligible.
...
If this is done, then XORing and concatenation should be equally effective.

The difference is that XORing can produce an output weaker than either input, concatenation cannot. The point is to protect against very unexpected failures without having to make assumptions about how well the underlying code is working. For example, you might write your code to use two different sources of entropy but then someone realizes that one of your sources is weak and so changes it to use a better source and now you're not using different sources anymore. Concatenation is robust, XOR is not.

On the other hand, if source #1 and source #2 are similar or the same RNG that is suspected to be broken, then I believe concatenation and XOR to both be ineffective, because both of them are pretending that it's a safe assumption that an RNG found to lack entropy (i.e. is broken) can suddenly be redeemed by running it twice.

The idea is to tolerate the unexpected case where source 1 and source 2 are similar or the same. XOR doesn't. The best imaginable algorithm can't produce an output stronger than the sum of the strengths of all of its inputs.

If we didn't have to tolerate unexpected cases, we wouldn't need any of this. An algorithm that can make things worse in unexpected cases is a bad idea, especially when it's so easy to make algorithms that don't.

[casascius]

In support of this, in my case, I've suggested that two sources of entropy should be so different such that the possibility of them being broken in the same way is negligible.
...
If this is done, then XORing and concatenation should be equally effective.

The difference is that XORing can produce an output weaker than either input, concatenation cannot. The point is to protect against very unexpected failures without having to make assumptions about how well the underlying code is working. For example, you might write your code to use two different sources of entropy but then someone realizes that one of your sources is weak and so changes it to use a better source and now you're not using different sources anymore. Concatenation is robust, XOR is not.

On the other hand, if source #1 and source #2 are similar or the same RNG that is suspected to be broken, then I believe concatenation and XOR to both be ineffective, because both of them are pretending that it's a safe assumption that an RNG found to lack entropy (i.e. is broken) can suddenly be redeemed by running it twice.

The idea is to tolerate the unexpected case where source 1 and source 2 are similar or the same. XOR doesn't. The best imaginable algorithm can't produce an output stronger than the sum of the strengths of all of its inputs.

If we didn't have to tolerate unexpected cases, we wouldn't need any of this. An algorithm that can make things worse in unexpected cases is a bad idea, especially when it's so easy to make algorithms that don't.

Given the assumption of doing something to hedge against a bad RNG versus nothing, I agree with you on both points.