[ANNOUNCE] Android key rotation

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

[1715068024]

1715068024

[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