Topic: BIP 38 Discussion Thread - Passphrase-Protected Private Key Format - page 3. (Read 8735 times)

I am starting a discussion thread on the technical merits and cryptographic soundness of my recent proposal for passphrase-protected private keys.

https://en.bitcoin.it/wiki/BIP_0038

The core features are:
* Encrypted keys are fifty-eight Base58Check-encoded characters starting with "6P"
* Encryption uses AES-256.  Key derivation uses scrypt.  Parameters are fixed at 16384,8,8; unused space in key format allows future specification changes.
* Typo detection is a 32-bit hash of the resulting bitcoin address and requires the full derivation and decryption process in order to be checked, so it does not provide any speedup to crackers.  These 32 bits are also used as salt.
* An elliptic curve multiplication step is selectable, allowing a scheme where Alice can select a passphrase and Bob can generate and fund bitcoin addresses that only Alice can decrypt; the specification describes what Alice must give to Bob to let that happen without divulging her passphrase, and defines a Base58Check-encoded format for it.
* Both compressed and uncompressed public key formats are selectable.

Fully functional proof-of-concept code has been published at https://github.com/casascius/Bitcoin-Address-Utility

I recently ran a contest where I created an encrypted paper wallet with a 5-letter password, loaded it with 10 BTC and published the encrypted private key, asking people to crack at it.  It took two days, the eventual winner threw 20 machines at it, and won only after I had leaked enough information about the password to reduce the search set to under 6 million possible passwords.  His estimate on how long it would have taken him to search the entire (reduced) search set was 45 to 60 hours.

My hope is that my proposal will be viewed as secure enough for implementation everywhere as a standard, anywhere someone is asked to provide a private key for any reason.  This includes any private key sweep or import functions in the Satoshi client.  In a user interface workflow, if a password-protected private key is entered, this should be auto-detected and the user would be asked: "Enter Password".  In an RPC context, the password would be another argument to calls.