Key store

[obscuren]

A new key store needs to be developed for genesis release. The current version has always been in a stand in for the final version.

Possible model

+----------------------+
| KeyStore - Generic   |
+----------------------+
          |
         \|/
+----------------------+
| KeyManager           |
+----------------------+
          |
         \|/
+----------------------+
| Wallet               |
+----------------------+

KeyStore is a generic interface and should potentially contains:

• Keys() []Key returns all keys currently in the KeyStore
• Store(Key) add a new key to the KeyStore
  If any encryption needs to be done for storing, the KeyStore should handle this. Store and Keys simply return keys (unencrypted).

KeyManager should accept a KeyStore as its backing mechanism. KeyManager need not to know about the implementation details of the KeyStore:

• NewKey() Key generates a new key and adds it to the key store.
• DeleteKey(Key) deletes a key from the key manager as well as the KeyStore

Wallet basic wallet functionality. Manages accounts currently in use, known and owned by the author. Creating transactions for specific accounts should also be handled by the Wallet.

[Gustav-Simonsson]

Types & Interfaces

type Key struct {
     Id *UUID                  // stdlib type. UUID version 4 - useful to have id not derived from key data. for e.g. key file name
     Flags [4]byte             // metadata flags, first bit indicates if stored encrypted
     PrivKey *ecdsa.PrivateKey // plaintext privkey using stdlib type
}

type KeyStore interface {
     GenerateNewKey() (*key, error)
     GetKey(UUID) (*Key, error)         // key from id
     GetKey(UUID, string) (*Key, error) // key from id, passphrase
     StoreKey(*Key) (error)             // store key without passphrase
     StoreKey(*Key, string) (error)     // store key encrypted with passphrase
     DeleteKey(UUID) (error)            // delete key by id
     ExportKey(UUID) ([]byte, error)    // TODO: export format/go type?
     ExportAllKeys() ([]byte, error)
}

type KeyManager interface {
     NewKey() (UUID, error)        // generates & stores key, returns key id
     NewKey(string) (UUID, error)  // same but with passphrase
     DeleteKey(UUID) (error)       // deletes key by id
}

Key generation

• 32 random bytes from CSPRNG [1] (dev/urandom or equivalent).
• Possibly mixing in of other entropy sources.
• Standard EC secp256k1 generation from the final bytes.

TODO: decide whether to mix in other entropy, for example some ethereum node state, if available, like current root hash of Merkle Patricia tree. Could be useful in case default OS CSPRNG is weak.

Key storage (default disk storage)

• One directory per file with one file containing privkey bytes.
• File permissions are read/write for the user running the go client.
• Default storage location is defaultDataDir + "wallet/keys/<key_uuid>/"

Passphrase encryption

• Mandatory by default in client GUI. Can be disabled with config option.
• AES-256-CBC for encryption of EC privkey.

TODO: KDF choice? scrypt [2] with high N value?
TODO: any objections to using CBC for cipher mode [3] for AES enc of privkey? ssh-keygen default is AES-128-CBC.

Key export / backup

TODO: encrypted key export format? Bitcoin WIF [4] for plaintext ones?
TODO: should default key store produce a file?

References

1. http://en.wikipedia.org/wiki/Cryptographically_secure_pseudorandom_number_generator
2. http://en.wikipedia.org/wiki/Scrypt
3. http://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
4. https://en.bitcoin.it/wiki/Wallet_import_format

[Gustav-Simonsson]

Edited key struct to use stdlib UUID and ecdsa.PrivateKey types.

[Gustav-Simonsson]

Scrypt params test: https://gist.github.com/Gustav-Simonsson/39801db33f0a11239eb8

On a Intel Core i7-3517U CPU @ 1.90GHz (ivy bridge, 3 years old laptop):

With N = 2^18, r = 8, p = 1 we get CPU time of 1s and 256MB memory used.
With N = 2^17 both CPU and memory is halved to 0.5s and 128MB.

If we are OK with scrypt for KDF we can tune this to have as high params as possible without compromising usability & support for older computers.

Another note is that https://bitcoinarmory.com/ adapts the scrypt params for the particular system it runs on before using scrypt as KDF. Pretty cool.

[Gustav-Simonsson]

WIP branch with to-be-squashed WIP commits: https://github.com/Gustav-Simonsson/go-ethereum/tree/new_key_handling