TippingPoint
Legendary
Offline
Activity: 905
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 19, 2013, 10:02:24 PM |
|
Listen to him ^ ^
|
|
|
|
justusranvier
Legendary
Offline
Activity: 1400
Merit: 1013
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 19, 2013, 10:07:04 PM |
|
...or use BIP32 to generate the addresses.
|
|
|
|
weavejester
Newbie
Offline
Activity: 22
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 01:40:29 AM |
|
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
Legendary
Offline
Activity: 1552
Merit: 1047
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 02:18:11 AM |
|
"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
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 03:15:17 AM |
|
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)
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
WinVery.com
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 04:49:04 AM |
|
This will never happen as required in full. Sounds like a job for a mop.
|
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:22:20 AM |
|
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.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
niko
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:39:12 AM |
|
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.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
Hawkix
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:45:59 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:49:19 AM |
|
...
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
Legendary
Offline
Activity: 1596
Merit: 1012
Democracy is vulnerable to a 51% attack.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 06:49:29 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.
|
I am an employee of Ripple. Follow me on Twitter @JoelKatz 1Joe1Katzci1rFcsr9HH7SLuHVnDy2aihZ BM-NBM3FRExVJSJJamV9ccgyWvQfratUHgN
|
|
|
🏰 TradeFortress 🏰
Bitcoin Veteran
VIP
Legendary
Offline
Activity: 1316
Merit: 1043
👻
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 10:10:52 AM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 11:55:42 AM |
|
Listen to him ^ ^
+1 He is a wise amn.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
weavejester
Newbie
Offline
Activity: 22
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 01:46:19 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.
|
|
|
|
TheKoziTwo
Legendary
Offline
Activity: 1552
Merit: 1047
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 01:51:32 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) 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
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 02:33:02 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. doesn't make much difference if you feed it through sha256 in the end.
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 02:35:46 PM |
|
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".
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
molecular
Donator
Legendary
Offline
Activity: 2772
Merit: 1019
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 02:36:38 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) 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?
|
PGP key molecular F9B70769 fingerprint 9CDD C0D3 20F8 279F 6BE0 3F39 FC49 2362 F9B7 0769
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 04:38:34 PM |
|
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.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
August 20, 2013, 04:41:45 PM |
|
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.
|
Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable. I never believe them. If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins. I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion. Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice. Don't keep coins online. Use paper or hardware wallets instead.
|
|
|
|