Encrypt wallet #3

Often requested feature: encrypt private keys in the wallet.dat file, so a password is required for a send transaction.

I think we can be creative about the way to input the password. IMHO it should be similar to the Android. It is really awesome and forces you into thinking about something more abstract. :)

How does Android do it? Got a reference?

I jotted down some thoughts here: https://gist.github.com/803170

I think this is a key feature. Manually backing up and securing your wallet really sucks, I think this keeps a lot of users from using BitCoin. Also there should be possible to specify wallet location. This way I would keep my wallet in my dropbox and therefore would take care of backing up.

The Andriod way of inputting your passcode (assuming you mean what you think I mean) is kind of a 'connect the dot' system, where you slide your finger from the first digit directly to the second. This has the implication of actually being less secure than using the traditional tap per digit system, because it limits the number of neighboring digits to 8 as opposed to the full 10. With the andriod way, if the first digit for your password is 5, then your possible choices for a second digit are 1,2,3, 4 and 6, and 7,8,9. However, consider what happens when your starting digit is 1, your next available digits become 2, 4 and 5. With the traditional method, no matter what key you start on, you may choose any other 0-9 number. I do applaud the creativity and innovation, but I think the security implications need to be pointed out.

I would like if my wallet was encrypted taking advantage of my already existing GnuPG key. :)

Suppose we encrypt keys with the public key of a separate private key. That private key is encrypted with a symmetric algorithm, whose key is derived from the passphrase. I believe this is how GnuPG works. When we store this encrypted key in the wallet, we also store a reference to the associated private key. (Or, perhaps have it elsewhere on the file system... usb drive? smart card? keyring?) With this functionality, we could prompt the user for a password once and decrypt multiple keys. It also means that a wallet could be separated into virtual partitions with different encryption keys. I think it would allow a smooth transition, but would it be backwards compatible?[1]

Here's the way I imagine interacting with this. I would keep a small amount of bitcoin in the clear. This allows me to easily spend the small amount while assuring I won't lose much if my device is compromised (good for mobile devices). I can easily encrypt/decrypt keys by entering a target amount to "transfer". The actual amount is determined by picking keys with transactions (outputs?) summing to approximately the target. In order to spend more than is in the clear, I must enter one (or more) passphrases, but the rest is automated.

[1]Can the structure of the wallet be modified for encrypted keys and a reference to the encrypting private key without causing a breaking change?

Fnordsoft, I hope the GPG mechanism is simpler - the pass phrase is hashed into a symmetric key, and that key is used to encrypt the sensitive data in the wallet. Much simpler, and you don't have to worry about storing a private key anywhere. The user enters the pass phrase, and the program checks it by encrypting something with the public key, then decrypting it with the private key, and ensuring that the resulting 'something' matches the original 'something'.

As for the input, keep it simple: there's nothing wrong with the plain ol' keyboard. The Android style may work well on a mobile device, but would be a royal pain in the *** anywhere else.

jhyslop, but many of us already use GnuPG with public key cryptography, so we're already storing private keys which we use for other purposes. Adding one more key is trivial.

I see no reason why both symmetric and public key cryptography couldn't be available as an option. Aside from the obvious "who will program it" part.

OK, I see what you're getting at, Jeff. Yeah, that could be an option. The default, I think, should be to use the hashed pass phrase as a symmetric key, with an option to allow advanced users to provide a public key.

By the way, just to clarify - when I said "the default should be to use the hashed pass phrase as a symmetric key" (HPPASK) I wasn't necessarily pushing HPPASK as The Solution. To generalize my statement, what I meant was "the default should be some password mechanism that keeps the wallet self-contained, and by the way the HPPASK seems to me a simple solution that meets the needs."

Couldn't find how to assign myself tickets, but I'm working on this. So give me a couple of weeks (focus on other issues) if possible ;) (don't like duplicating work). BTW I'm using a symmetric key (AES now, but easy to switch to blowfish .etc) with the passphrase hashed with RSA using OpenSSL. If you're interested then run 'man evp_sealinit' or man evp_openinit.

An alternative (or stop-gap measure) to encrypting the wallet could be to allow the user to specify where the file should be. This way, he can place it on an encrypted volume (that he may already have for other important documents).

My proposal: wallet.dat zipped and encrypted. How effective is break password by brute force? One step can require verify all file?

First time user experience. I am a developer, but would like to shed light on what I encountered when discovering the world of Bit Coins.

After reading a taste of what BCs were I download the client (developer side) and fired it up (OSX). I was met with a string of characters not too frightening for a developer and especially not when expecting crazy encryption fun times to be going on. However, I didn't quite know what I was looking at or what it meant to me. I stumbled onto Bit Faucet and it introduced the notion that these characters were an address used to receive BC. So I learned something. At some point I clicked "New..." and my string of characters changed; this befuddled me a bit. Some more reading calmed me as it was "good practice" to generate these new addresses and use them liberally.

As I continued to learn about what I had gotten myself into it came to light that the client I had downloaded was the key to whatever BTC I began to acquire. So as a developer, my first questions were, "where is the secret key?", "how do I protect it?", and "how do I move it and still use this client?". All of these questions are being touched on in IRC and in this thread. So I'm glad to see the discussion is taking place. However, I have yet to see reasonable discourse that talks about what sort of experience our target end-user should see. When starting a conversion in IRC #bitcoin-dev about the above questions I quickly received answers such as: "just backup your wallet.dat file", "use truecrypt", "use gpg", "use a USB stick or dropbox", et cetera. My response is... DUH! The point of the discourse was not to get an answer I am perfectly capable of doing as a developer. It was to discuss how to make Bit Coins and the associated software accessible to our girlfriends, mothers, and fathers. So, with all of that context, and as a development brother looking at my experience as a first time user (while it is still fresh, I discovered BC two days ago and now have 40BTC, yay), I'd like to suggest the following:

• Do NOT generate the secret magic sauce upon the client first loading, instead, provide an introduction screen that says, "Hey, welcome to the world of Bit Coins! Let's walk through a few concepts before you get started". Introduce the high-level concepts of: 1) you will be creating a wallet, 2) you generate "addresses" which others use to send you Bit Coins 3) your wallet is the key to accessing your Bit Coins, if you create another wallet on a different device, you will have two different "accounts" (like at a different bank)
• Prompt the user to create a wallet, have the default directory available, but at least introduce them to where this super sensitive information is. Then show a generating magic sauce message with a repeated explanation that THIS IS IMPORTANT
• I personally suggest integrating TrueCrypt as a sub-system of the BC client. Use a true crypt volumes to store either just the sensitive files or everything (good when using a portable USB key). Prompt the user to enter a passphrase so the true crypt volume can be created and used. People are used to passwords, opening the BC client and being prompted for a password by default won't alarm anyone.
• True Crypt has done work to be used on portable devices. I recommend Bit Coin do the same and be completely runnable via a USB stick.
• Provide a GUI level option to "backup your wallet" (ie. make a copy of the true crypt volume somewhere else). It would also be handy to be able to name your wallets and prominently display it in the client. When backing up the name would default to "Wallet Backup 2011-02-16" and the wallet would be marked as a backup. If a client opens a backup wallet, a warning could be issued stating as much and asking if this should now be considered a primary wallet (in the event of a restore)

My suggestions focus on education and features crucial to the adoption of Bit Coins, in my opinion. I cannot feel good about telling a non-techy about Bit Coins without these features. I want to be able to tell my girlfriend and her be able to make sense of the experience on her own. Thanks for all of the hard work thus far and I'm really enjoying my foray into the Bit Coins community.

Cheers,

If TryCrypt give anything? It joins file as disk. This disk is readable to other programs (trojans), only advantage TryCrypt is defense against read wallet.dat when someone steals computer.

As far as I see, this discussion was not about malicious software on the device in which the wallet.dat file was being stored. Trojans could be a problem now, and you are correct, they could be a problem when using True Crypt. To clarify, the goal of using True Crypt is as you said, to protect against theft when one no longer has access to their device OR when the bit coin client is not running (in this case, trojans mean nothing).

Not to derail the conversation onto malware, but I see no reason to have the wallet.dat file (or other sensitive files) open when not needed. I cannot speak to the internals of how the wallet.dat file is used, but I would summise there could be a way of "locking" or un-mounting the True Crypt disk when the client is not using it and prompting when necessary. That could get annoying, but more discussion on real-time protections should be in another thread. As I see it, this discussion concerns some level of inherent encryption built into the client. To be fair, my mentions of "backups" should be in another thread as well, but the topics tend to be mentioned together.

Thank you for the opportunity to clarify.

Encrypted or not, I strongly advocate a plaintext wallet. Encryption DOES NOT help backup the wallet. It does mean (to a minor extent) that you don't need to be quite as careful with where you backup, but you should ALWAYS backup.

As it is, I've got multiple copies of three wallet files on the same media because I am too scared to delete some of them, despite the fact that the addresses are redundant. I can not 'diff' the files, so my backup solution is just copy copy copy. If I ever need to recover, I'll probably have to load a hundred versions of all my wallets looking for loose change. If the wallet were plain text, I'd keep ONLY the key pairs I need and never duplicate them (on the same media).

For similar reasons I disagree with the keypool=100 hack because it presents a false sense of security. Eventually (after the 100th key pair) a restoration from backup will blow away real money.

And yes, you can have plain text and encryption as a radix64 key block.

I'd love to see a scheme like in SSH, where the private keys can be encrypted, and a password is then required for using them. Make it optional for all I care, but personally if someone should be able to obtain my wallet.dat it should be useless to them without an extensive amount of work (say brute-forcing my password). Keep private keys encrypted on disk, decrypt for usage (where usage is "signing an outgoing transaction"), and wipe the memory area after use. To be a bit more technical; HPPASK is pretty much the scheme of choice, with a resource-intensive hash like PBKDF2 with lots of rounds... +1

Encrypting private keys pulled. Closing this request.

When unlock wallet , the decrypted mater key is stored in memory. Why use the mater key to encrypt private key ? Why not use the key derived based passphrase. Why the decrypted mater key is stored in memory, why not decrypted privated key?

Often requested feature: encrypt private keys in the wallet.dat file, so a password is required for a send transaction.

I dowlanded bitcoin core but without create account and encrypt private keys i send small amount btc now I can't send btc what is the reason? If i encrypt keys will I lose my bitcoin please help!