The primary goal of this format is to create something like
PKCS#8/RFC5958. PKCS#8 is the format commonly used to store SSL/TLS private keys, in password-protected form or otherwise. It is a very flexible format with metadata describing of the type of private key, and the PBKDF parameters and block cipher used to encrypt it.
It's possible to convert an exported bitcoin private key in the base-58 format to and from PKCS#8. In PKCS#8, the built-in password-protection feature can be applied to the private key. Also, if a bitcoin key were to be imported into some other non-bitcoin application for whatever reason, perhaps as a signing key, PKCS#8 would be the best bet as an import format.
It's also possible to take a PKCS#8 representation and produce a reduced mapping that assumes certain parameters. If we assume the use of the SECG 256k1 EC curve, a set of of PBKDF2 parameters, and the use of AES with a specific key size, the representation can be smaller. Unfortunately, due to
RFC5915, there is a practical lower limit on the size of any reduced format. For bitcoin private keys, this is close to 135 bytes, and it includes numerous details that, for our purposes, aren't necessary or can be assumed. This is unwieldy large.
The next step of evolution from PKCS#8 might work as follows.
privkey = Minimal EC private key representation, 32 bytes long
param = Parameter descriptor byte. This is an index into a predefined list of parameter groups, perhaps like:
- 0: SECG 256k1 key, PBKDF2, HMAC-SHA256, 8-byte salt, 4096 iterations, AES-256-CBC
- 1: SECG 256k1 key, PBKDF2, HMAC-SHA256, 8-byte salt, 4096 iterations, Camellia-256-CBC
- 2: SECG 256k1 key, PBKDF2, HMAC-SHA256, 8-byte salt, 16384 iterations, AES-256-CBC
- etc..
pbhash = Hash function from parameter list
cipher = Block cipher function from parameter list
salt = Random salt value of size described in parameter list
iter = PBKDF iteration count described in parameter list
pbkey =
PBKDF2(password, salt, pbhash, iter)protkey =
param | cipher(privkey, pbkey) | saltThis would handle the cryptography in the most conservative, commonly-used way, and should not make anyone nervous, or at least, not any more nervous than PKCS#8. It would also make the format easily adaptable to new block ciphers and key derivation functions. The smallest representation using AES would be 58 bytes long, and would convert to an 83-character base-58 string. This is much more compact than a PKCS#8 interoperable format, but I still think it's too long.