[ANNOUNCE] Android key rotation - page 2.

weavejester

newbie

Activity: 22

Merit: 0

Quote from: Hawkix on August 20, 2013, 02:49:19 AM

Quote from: weavejester on August 19, 2013, 09:40:29 PM

...

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.

Lauda

legendary

Activity: 2674

Merit: 2965

Terminated.

Quote from: TippingPoint on August 19, 2013, 06:02:24 PM

Listen to him ^ ^

+1
He is a wise amn.

🏰 TradeFortress 🏰

vip

Activity: 1316

Merit: 1043

👻

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://bitcointalksearch.org/topic/blockchaininfo-security-funds-stolen-277595

JoelKatz

legendary

Activity: 1596

Merit: 1012

Democracy is vulnerable to a 51% attack.

Quote from: niko on August 20, 2013, 02:39:12 AM

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.

Hawkix

hero member

Activity: 531

Merit: 505

Quote from: weavejester on August 19, 2013, 09:40:29 PM

...

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?

Hawkix

hero member

Activity: 531

Merit: 505

Quote from: niko on August 20, 2013, 02:39:12 AM

Quote from: molecular on August 20, 2013, 02:22:20 AM

Quote from: casascius on August 19, 2013, 05:57:36 PM

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

niko

hero member

Activity: 756

Merit: 501

There is more to Bitcoin than bitcoins.

Quote from: molecular on August 20, 2013, 02:22:20 AM

Quote from: casascius on August 19, 2013, 05:57:36 PM

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.

molecular

donator

Activity: 2772

Merit: 1019

Quote from: casascius on August 19, 2013, 05:57:36 PM

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.

WinVery.com

full member

Activity: 235

Merit: 100

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

casascius

vip

Activity: 1386

Merit: 1136

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: TheKoziTwo on August 19, 2013, 10:18:11 PM

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)

TheKoziTwo

legendary

Activity: 1552

Merit: 1047

"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?

Quote from: casascius on August 19, 2013, 05:57:36 PM

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?

weavejester

newbie

Activity: 22

Merit: 0

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.

justusranvier

legendary

Activity: 1400

Merit: 1009

...or use BIP32 to generate the addresses.

TippingPoint

legendary

Activity: 905

Merit: 1000

Listen to him ^ ^

casascius

vip

Activity: 1386

Merit: 1136

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

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.

molecular

donator

Activity: 2772

Merit: 1019

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?

BurtW

legendary

Activity: 2646

Merit: 1136

All paid signature campaigns should be banned.

Quote from: Gator-hex on August 19, 2013, 01:43:19 PM

Quote

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

Wink

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.

Gator-hex

hero member

Activity: 490

Merit: 500

Quote

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

Wink

niko

hero member

Activity: 756

Merit: 501

There is more to Bitcoin than bitcoins.

Quote from: Rannasha on August 19, 2013, 11:21:17 AM

Quote from: allbiznessman on August 19, 2013, 11:08:40 AM

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.

Carlton Banks

legendary

Activity: 3430

Merit: 3074

Quote from: casascius on August 14, 2013, 01:27:18 PM

Quote from: ReCat on August 14, 2013, 11:43:07 AM

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 Cheesy

)

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? Grin

Topic: [ANNOUNCE] Android key rotation - page 2. (Read 66313 times)