That's fantastic, Maged. He also mentions in that thread an idea which I've wanted to figure out for a while: how to create a generator that can be kept offline, but still generate it's public addresses/keys from an online computer without the private key.
That's a very fascinating thread, and I will also need to read ByteCoin's proposal a little more closely. Thanks! And sorry for the repost! I'll work on my searching skills...
-Eto
Topic: Deterministic Wallet Generation (repost?) (Read 890 times)
I can't believe I'm the first person to ever mention this idea, but I can't find reference to it anywhere else on the forums. Perhaps I just suck at searching
It's right here on page 1 of this board:https://bitcointalksearch.org/topic/deterministic-wallets-19137
Thoughts?
This seems like a very good idea. A private key backup would be valid forever not just for the next 100 transactions.
hrmm could work
Not true, the devs will just update the client to use a different hashing technique.
Problem (3) is a problem only if double-sha256 hashing is broken, and if so, all of BTC is screwed.
Not true, the devs will just update the client to use a different hashing technique.
I can't believe I'm the first person to ever mention this idea, but I can't find reference to it anywhere else on the forums. Perhaps I just suck at searching. I found a few similar posts, but most are based on remember-able passwords, which I am not proposing. Sorry I've mentioned this in a few different posts, but I wanted to start a dedicated thread for wider feedback.
I would like to see the current address pool technique in the wallet replaced with a process of deterministic key generation. The idea is that when a user first fires up Bitcoin, it will either generate a random 256-bit key for them, or the user can supply their their own random bits (flip a coin 256 times, put results in a file). The point is for them to have a full 256-bits of entropy in this "generator," so there is no need for key stretching or any kind of salting, nonces, etc. This would be the "master" key for that user forever (or until they decide to change it). After that, every time the user needs a new address, the client calculates it via:
This provides a semi-infinite number of private keys that can always be recreated only from the original generator key. Then the user only has to backup one file, ever. Save it to paper in a safe-deposit box, or get it tattooed to the underside of your eyelid, because you never need to update your backup.
I only see three potential problems:
Problem (1) is "easily" addressed. If the client creates the generator key for the user, it could go through a process of pulling entropy from mouse and keyboard events, or known physical processes that can be measured from the user's computer, such as thermal/voltage oscillations in CPU/PSU, RAM cell values after reset, etc. The client could be set to reject anything that isn't exactly 256-bits or contains too much human-esque entropy. The user would have to either use the client dialog for creating the generator, or figure out how to supply real entropy.
Problem (2) doesn't actually seem like much of a problem to me. I can't think of any attack that would compromise one private key of a user and not all of them. They're all stored in a single wallet file, and any attacker is going to copy the whole file if they get access to it. So, by reducing your entire wallet to one private key, I'm not sure any security is lost.
Problem (3) is a problem only if double-sha256 hashing is broken, and if so, all of BTC is screwed. It could be replaced by sha256^10 if it makes anyone feel better, or a mixture of hashes, and self encryptions (perhaps use itself as an AES password to encrypt itself before hashing).
Simple, secure, and useful. Thoughts?
I would like to see the current address pool technique in the wallet replaced with a process of deterministic key generation. The idea is that when a user first fires up Bitcoin, it will either generate a random 256-bit key for them, or the user can supply their their own random bits (flip a coin 256 times, put results in a file). The point is for them to have a full 256-bits of entropy in this "generator," so there is no need for key stretching or any kind of salting, nonces, etc. This would be the "master" key for that user forever (or until they decide to change it). After that, every time the user needs a new address, the client calculates it via:
Code:
PrivKey[i+1] = sha256(sha256( GenKey XOR PrivKey[i] ))
This provides a semi-infinite number of private keys that can always be recreated only from the original generator key. Then the user only has to backup one file, ever. Save it to paper in a safe-deposit box, or get it tattooed to the underside of your eyelid, because you never need to update your backup.
I only see three potential problems:
- (1) Weakest link would be the random number generator.
- (2) If master key is compromised, so is every wallet address.
- (3) Weaknesses due to "relationship" of keys via SHA256
Problem (1) is "easily" addressed. If the client creates the generator key for the user, it could go through a process of pulling entropy from mouse and keyboard events, or known physical processes that can be measured from the user's computer, such as thermal/voltage oscillations in CPU/PSU, RAM cell values after reset, etc. The client could be set to reject anything that isn't exactly 256-bits or contains too much human-esque entropy. The user would have to either use the client dialog for creating the generator, or figure out how to supply real entropy.
Problem (2) doesn't actually seem like much of a problem to me. I can't think of any attack that would compromise one private key of a user and not all of them. They're all stored in a single wallet file, and any attacker is going to copy the whole file if they get access to it. So, by reducing your entire wallet to one private key, I'm not sure any security is lost.
Problem (3) is a problem only if double-sha256 hashing is broken, and if so, all of BTC is screwed. It could be replaced by sha256^10 if it makes anyone feel better, or a mixture of hashes, and self encryptions (perhaps use itself as an AES password to encrypt itself before hashing).
Simple, secure, and useful. Thoughts?
Jump to: