Topic: [PULL] Wallet Private Key Encryption (Read 16634 times)

Ideally the private elliptic signing keys would be stored on a one-way device, but even storing the encryption key has the advantage that an attack on a copied wallet must be launched against the symmetric key (DES3, IDEA, etc) or asym RSA rather than a human generated passphrase.

In the Settings menu, it shows up for me.

The menu option to encrypt your wallet didn't show up in the windows build, is there something else I'm missing?

Your OpenPGP card is for RSA keys like the most (perhaps even all) smart cards which you can buy in small amounts so you cant store Bitcoin keys as keys on it. If your card has some memory for data objects than you can use this patch https://forum.bitcoin.org/index.php?topic=8091.0 for storing but this would be more or less the same as storing on an encrypted USB stick.
 

Nice, thanks

Pulled, should show up on the next nightly build (see my sig).

I wonder if the proposed implementation would allow the actual keys to be stored on a smart card, much like the OpenPGP smart cards that kgo is selling ( http://forum.bitcoin.org/index.php?topic=26918 ). Or otherwise include some physical factor? The smart card memory limits the number of keys stored, but that is not likely a problem for a 'savings' wallet with a finite number of recycled keys.

I just have to say that as soon as this gets implemented, the market price of bitcoin will quite likely go up. I don't know of a more critical addition on the development side that could enhance the bitcoin value more so than wallet encryption.

The encryption process is just simple take old keys (including addresses, pool keys, etc) and encrypt the private part.  No crazyness, the same keys are still kept so your backups still have the keys to your coins (until new keys are generated).

when going from an unencrypted wallet and then adding a password, what happens to the addresses that may already have had bitcoins and other addresses that were in the keypool but had not yet been used?

in other words, after i encrypt are those coins now at password-protected addresses?  or does the situation exist where access to one of my old backups of my wallet.dat mean i could still lose those coins that haven't been spent (or moved as part of a change transaction) since the point that i started running with encryption?

It is.

I still think encryption should be disabled by default. One issue I have seen in the forums is that many users are not even aware a file called "wallet.dat" exists; and that portions are secret. Upon learning about it, the first thing demanded is some kind of encryption like GPG.

Of course, with money on the line; you don't ever want the user to accidentally forget the passphrase. Getting a passphrase right is difficult, even if you know what you are doing. That is why I think the user should be assigned a randomly generated passphrase.

I guess I am advocating an "all or nothing" approach. If passwords don't really enhance security because they are too short, why bother?

There was discussion on IRC about having a "recovery code" which users were forced to write down in this manner... not to address the password security issue— no password people will be comfortable typing every time they spend will be secure, but to address the very real outcome that encryption is going to increase the amount of btc lost by people, because theft is uncommon (especially the narrow set of theft that encryption stops) but forgetting things is fairly common.

I had a thought: The user should not choose the password. the average user does not know how to choose secure passwords.

The user should be presented with a random 24 character base58 passphrase (128bits of entropy) and told to write it down twice. One copy should be kept off-site somewhere such as a safety-deposit box. After the user clicks "OK" without reading the message, the user should be prompted to enter the passphrase they just copied down. If they fail to enter the passphrase, they should be reminded that losing the passphrase is equivalent to deleting their money permanently*.

Of course, some (most) people will find such a long passphrase inconvenient. I think encryption should be optional. Though, I think a better approach would be support for multiple wallets: One with no encryption for petty cash/impulse purchases, and another for a wallet that is only accessed occasionally to pay bills. A savings wallet should not be stored on the computer at all; though the address for the savings wallet should be.

*Edit: I don't mean the nag screen should be permanent...
Edit: only one copy (the off-site one) of the passphrase would need to be written down if a smart-card is used to store an "easy to use" copy unlocked with a short pin.

You essentially want separate wallets, which is a very useful feature, but not really what accounts are intended for. I think we should rather try to move to a general system where the client can open more than one wallet file at the same time, and provide built-in possibilities to move coins from one wallet to another.

Yeah, that would be really great. For my online-wallet I'd also like the keys for each user to be encrypted separately.

Would there be problems with bitcoin trying to use transactions from different accounts as inputs? What about change?
Would it be difficult to modify the sending code to choose only inputs from the given account and also use a change address from this account?
Has this been discussed already, or does it warrant a new thread?

FYI, just noticed there is now a metasploit module that collects wallets. Thats exactly the kind of thing that is solved by this feature.

https://dev.metasploit.com/redmine/projects/framework/repository/revisions/12993/entry/modules/post/windows/gather/bitcoin_jacker.rb

Just to set the record straight.  I'm sorry with how I handled your suggestions, I didn't fully think through, nor read the IV-related bruteforce things, you are right. I still disagree with the move away from EVP things for the reasons discussion on the pull comments.  I plan on rewriting based on wallet class anyway, and will implement something similar to what Pieter propsed +/- some stuff.

Suggestion to improve upon all concerns, making sure each and every crack attempt requires: 1) iterated key strengthening 2) AES decryption 3) EC point multiplication 4) RIPEMD160+SHA256 hashing:

Master keys are stored using a db record:

• KEY = ("mkey", id)
• VAL = (salt, iterations, AES(key+iv=KeyDeriveSHA512(passphrase_id, salt, iterations), data=masterkey))

Wallet keys are stored using a db record:

• KEY = ("ekey", versionByte_n, RIPEMD160(SHA256(pubkey_n)))
• VAL = AES(key=masterkey, iv=RIPEMD160(SHA256(pubkey_n)), data=privkey_n)

Both legitimate access and crack attempts need to (for each mkey entry, until a match is found):

• perform iterated key derivation from the passphase and the mkey's salt, to find key/iv for the masterkey
• Decrypt an ekey's data using it
• Do EC point multiplication on the decrypted privkey to find the pubkey
• Hash the pubkey twice
• Compare this hash with the ekey's KEY

Depending on which encryption algorithm is used, RIPEM160(SHA256(pubkey_n)) may not have enough bits to use as IV, but I'm not sure to what extent that is an issue. Alternatively, a much shorter identifier-based ekey KEY can be used, making it even harder to verify a passphrase is correct (you'd need to go looking for transactions matching the given address and so on... this would be so fuzzy that some checksum-based verification mechanism would need to be put in place, making cracking a bit easier again as well). Another alternative is adding a additional nonce to ekey's VAL, used as IV.

The reason for "versionByte_n + RIPEMD160(SHA256(pubkey_n))" in the ekey's KEY, is that it matches addresses, and could be used in the future when the entire wallet isn't loaded from disk anymore. This is probably not really an issue now.


EDIT: as public keys are stored unhashed in several places in the wallet file anyway (txouts, keypools, ...), an attacker does not need to always do the RIPEMD160(SHA256(pubkey)) operation to verify correctness.

gmaxwell: You are right. With the current proposed system, if you have a large table with (scheduled) AES keys derived from many popular passwords, the work to attempt a crack is a single AES decryption per wallet and per passphrase (as the current serialized privkeys contain a pubkey, only a comparison with the known pubkey must be tried after decrypting).

With Gavin's suggested improvement (only storing the private parameter instead of the entire serialized key), this becomes 1 AES decryption + 1 EC point multiplication. If the ekey's key is modified to have the address instead of the pubkey (as Gavin seems to imply), an addition SHA256 and RIPEMD160 hash are required to verify correctness.

With my suggestion to use a separate masterkey, it becomes 1 AES decryption of the master key, 1 AES key scheduling, 1 AES decryption of an ekey, 1 EC point multiplication.

Neither of these schemes take advantage of the key strengthening performed by EVP, as it can be done in advance (for simple passwords only).