[ANNOUNCE] Android key rotation

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

[1714151100]

1714151100

[1714151100]

1714151100

[1714151100]

1714151100

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