phatsphere
|
|
August 13, 2013, 12:33:08 PM |
|
@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.
|
|
|
|
casascius
Mike Caldwell
VIP
Legendary
Offline
Activity: 1386
Merit: 1140
The Casascius 1oz 10BTC Silver Round (w/ Gold B)
|
|
August 13, 2013, 12:39:35 PM |
|
@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.
|
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.
|
|
|
niko
|
|
August 13, 2013, 12:49:10 PM |
|
What casascius described sounds good. XORing even with a constant will certainly not decrease entropy. Thus, his method can only make things better.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
niko
|
|
August 13, 2013, 12:53:50 PM Last edit: August 13, 2013, 02:45:17 PM by 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.pdfWhen 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.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
Huangww
Member
Offline
Activity: 115
Merit: 10
|
|
August 13, 2013, 03:10:14 PM |
|
very quick。
|
|
|
|
qwk
Donator
Legendary
Offline
Activity: 3542
Merit: 3413
Shitcoin Minimalist
|
|
August 13, 2013, 05:13:29 PM |
|
@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 ;-)
|
Yeah, well, I'm gonna go build my own blockchain. With blackjack and hookers! In fact forget the blockchain.
|
|
|
TippingPoint
Legendary
Offline
Activity: 905
Merit: 1000
|
|
August 13, 2013, 05:45:08 PM |
|
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
|
|
August 13, 2013, 07:07:02 PM |
|
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
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
August 13, 2013, 08:29:40 PM |
|
very quick。
It would be a huge problem if it wasn't quick enough.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
SgtSpike
Legendary
Offline
Activity: 1400
Merit: 1005
|
|
August 13, 2013, 08:45:49 PM |
|
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
|
|
August 13, 2013, 09:37:08 PM |
|
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
Newbie
Offline
Activity: 28
Merit: 0
|
|
August 14, 2013, 03:42:27 AM |
|
Did anyone get their mobile wallet BTC stolen?
|
|
|
|
|
niko
|
|
August 14, 2013, 05:33:34 AM |
|
Did anyone get their mobile wallet BTC stolen?
Yes. A total of 55 coins so far. https://bitcointalk.org/index.php?topic=271486.0The 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.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
wopwop
|
|
August 14, 2013, 10:30:58 AM |
|
pseudo random number generation used in security systems is nothing more than *security through obscurity*
|
|
|
|
|
Mike Hearn (OP)
Legendary
Offline
Activity: 1526
Merit: 1129
|
|
August 14, 2013, 12:36:52 PM |
|
That post is unrelated to issues on Android.
|
|
|
|
Jan
Legendary
Offline
Activity: 1043
Merit: 1002
|
|
August 14, 2013, 12:46:10 PM |
|
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.
|
Mycelium let's you hold your private keys private.
|
|
|
niko
|
|
August 14, 2013, 03:33:25 PM Last edit: August 14, 2013, 03:49:30 PM by niko |
|
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.
|
They're there, in their room. Your mining rig is on fire, yet you're very calm.
|
|
|
ReCat
|
|
August 14, 2013, 03:43:07 PM |
|
@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 )
|
BTC: 1recatirpHBjR9sxgabB3RDtM6TgntYUW Hold onto what you love with all your might, Because you can never know when - Oh. What you love is now gone.
|
|
|
|