Topic: Passphrase-protected private key format BIP proposal (plus working code) (Read 3940 times)

Locking this thread so we don't have two active threads on the topic: continue at https://bitcointalksearch.org/topic/m.1380271

I think I checked in UI elements to allow batch entry, but haven't written the code to actually parse them.

Much better system than what I hacked in to make it work. I'll do some testing but I love what you have here. Love the passphrase protected private keys as well.

Updated Github with ability to manually input your own private keys so you can print them as voucher notes.

Great!

Good idea to use salt. Looks sturdy.

awesome

I have finally gotten around to writing up a proposal and test implementation for my Passphrase-Protected Private Keys proposal.  I have requested a BIP number be assigned.

The proposal is at https://en.bitcoin.it/wiki/Casascius/BIP_draft_for_passphrase-protected_private_key

The code (Windows, with source) can be found at https://casascius.com/btcaddress-alpha.zip (minimally tested use at your own risk).

Also on github: https://github.com/casascius/Bitcoin-Address-Utility

HERE IS WHAT YOU CAN DO:

1. Encrypt private keys with a password, including print password-protected paper wallets.  Password-protected private keys start with "6P".  You can decrypt them with this utility.  I am hoping by making a BIP of the standard, that you can decrypt them anywhere a private key is accepted.  For example, you could use this to put paper wallets in your safety deposit box without worrying that somebody from the bank could snoop in your box, and then keep the password memorized or at home.

2. Encrypt a passphrase into an intermediate value that can be used to create two-factor password-protected physical bitcoins.  That intermediate value can be used to create new keypairs for physical bitcoins that can only be redeemed with the original passphrase.  That means you can choose a passphrase, send me the intermediate value, and then I can make passphrase-protected physical bitcoins that only you can redeem, without me knowing the passphrase.  (The "intermediate value" consists of some salt and an elliptic-curve point derived from your password).

All password derivation is done using scrypt and is properly salted, so password cracking is extremely difficult.  A secure password good enough for a website is good enough here - the standard isn't as high as, say, an unsalted SHA256-based brainwallet.

An example of how it works (method 1):

You pick a passphrase "Satoshi" and have the private key 5KN7MzqK5wt2TP1fQCYyHBtDrXdJuXbUzm4A9rKAteGu3Qi5CVR.
When you encrypt it with my tool, the result is 6PRVWUbkzzsbcVac2qwfssoUJAN1Xhrg6bNk8J7Nzm5H7kxEbn2Nh2ZoGg.
(Using this method, the resulting Bitcoin address is used as salt, so the same private key and passphrase will always yield the same encrypted result).

An example of how it works (method 2):

You pick a passphrase "Satoshi" and enter it into my tool (or somebody else's tool implementing my BIP)
The tool gives you the following intermediate code: passphraseoRDGAXTWzbp72eVbtUDdn1rwpgPUGjNZEc6CGBo8i5EC1FPW8wcnLdq4ThKzAS
(the code contains 64 bits worth of salt, so you get a different intermediate even if you re-encode the same passphrase)

You give me the intermediate code.  I use it to create a physical bitcoin.
The physical bitcoin has the address 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V and you fund it.
The code inside the physical bitcoin is 6PfLGnQs6VZnrNpmVKfjotbnQuaJK4KZoPFrAjx1JMJUa1Ft8gnf5WxfKd (just wait and see how I fit this long sucker inside my bar... don't worry it's just as legible as all my other codes)
I am unable to compute the private key with just the intermediate.

You enter this code and the original passphrase "Satoshi".  The decryption process is slow and takes several seconds, this maximizes your security against brute force attacks.
You get the unencrypted private key 5KJ51SgxWaAYR13zd9ReMhJpwrcX47xTJh2D3fGPG9CM8vkv5sH and can claim the funds for 1CqzrtZC6mXSAhoxtFwVjz8LtwLJjDYU3V.

EDIT: reduced the scrypt strength of the 2nd half of method 2 since it's unnecessary - the passphrase is crunched entirely in the 1st half.  This invalidates my previous example of method 2 and I updated it.  I don't expect anyone is relying on these yet given this is merely a proposed draft, but just in case, if you've created any with the previous version, use the same version to decrypt it.