Topic: [ANNOUNCE] Android key rotation - page 5. (Read 66313 times)
BTCy the way, my import/export keys menu options are greyed out. What do I do? How can I get my BTC?
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 .
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?
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.
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.
IMO it doesn't make much difference. We could implement it, but it would not have avoided the need to do a key rotation.
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
Is there any reason why Bitcoin clients shouldn't use this construction, other than perhaps the possible newness of this exact instantiation?
roy
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. 
Whoa whoa, I've just transferred all my BTC from an Android wallet to inputs.io.
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.
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.
Fixed?
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.
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 …
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.
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!
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.
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.
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 …
i think it depends on the browser …
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.
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.
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! 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 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
Jump to: