I would love to see functionality similar to the following in the client:
Generate a new key from the hash of a long phrase you memorize. Transfer the bitcoin to this key then destroy the wallet. Your wealth is in your head now!
Later recreate the key from the memorized phrase and recreate the wallet.
The objection I got is that the user can be negligent and use weak passwords. This, of course, is a weakness of any cryptographic protection of keys or wallets. The true objection is that there is a transaction out there in the public block chain transferring coin to your key that is subject to a dictionary attack. A thief could scan the block chain for keys generated by weak passwords. He’s not targeting you in particular, but, given human nature, he will harvest a few if this method of generating keys gets popular.
There is a way to make dictionary attacks more difficult. It involves using a salt and increasing the time / work required to check each key. So I propose the following functionality:
• The client can be instructed to put aside the main wallet and create a “shadow wallet” at any time.
• The shadow wallet resides in RAM and is never put on the hard disk. It is actively cleared from memory when the user is done with it and switches back to the main wallet. (Any tricks to keep it off the swap files during memory management should be used.)
• The shadow wallet is created by generating 100 keys seeded from a user passphrase as described below. The idea is the user can go to ANY bitcoin client he trusts (on any machine he trusts) and bring up HIS shadow wallet by typing in his passphrase.
• The client runs through the block chain populating the key balances when the user swaps in a shadow wallet.
• To generate a salt: This has to be something unique to that user but is doesn’t have to be secret. I propose the salt be a hash of his full name. This is something he will never forget yet it is enough to thwart a scan of the block chain against a dictionary looking for weak passwords. The attacker would have to target YOU in particular to know what salt to use when checking keys.
• To increase the work load on the attacker: I propose the user pick a three to six digit pin that he must remember. The pin is mapped to a HASHCOUNT as in HASHCOUNT = A * PIN + B. Where A and B are chosen so that a pin of zero gives you a HASHCOUNT that a typical CPU can calculate in 60 seconds and a pin of 999999 gives you a HASHCOUNT that a typical CPU can calculate in 24 hours. The math has to be Integer math so the same exact HASHCOUNT is reproduced ten years later.
• Why 24 hours? Because ten years later a typical CPU will be much faster.
• The INITIALSEED is calculated as SHA256(passphrase, fullname, HASHCOUNT) and the final SEED is calculated as HASHCOUNT repetitions of SHA256(SHA256(SHA256 … SHA256(INITIALSEED))))
• The INITIALSEED includes a hash of the HASHCOUNT so the attacker can’t go exploring for the SEED. He has to start over for every guess of PIN.
So the user has to remember his passphrase, his name , and a small PIN (that he may choose to be zero if he is negligent). The attacker will despair because each key in the block chain he checks will take him a minute to a few hours to check against a SINGLE GUESS from his dictionary that may be 100,000 entries of common passwords. This is for an attack against a SINGLE USER that the attacker is targeting because each user will have a different salt.
This architecture completely solves the problem of protecting your standard wallet cryptographically someplace. (As a fall back for people who like to have a thumb drive in hand, you can have a tool generate a very strong passphrase and protect that encrypted on the thumb drive. Nothing at all to remember since with a super passphrase you can leave the fullname null and PIN at 000.)
