Interesting, although your layering/composing of different cryptographic schemes may come back to bite you.
As I see it, you want to encrypt the password and also verify that the encrypted bits are unchanged. Here's a slight modification of the above:
privkey = 32-byte EC private key, big-endian form
salt = 4-byte random salt value
symkey =
PBKDF2(HMAC-SHA1, password, salt, 4096, 64)cryptedprivkey =
(privkey XOR symkey[0:32])pwcheck =
HMAC-SHA1(symkey[33:64],cryptedprivkey)protkey = cryptedprivkey | pwcheck | salt- You should use the more recent PBKDF2 (http://www.di-mgt.com.au/cryptoKDFs.html), which allows you to produce arbitrary length keys. In this case we're generating a 64-byte length key, half of which we'll use for encryption and the other half for authentication.
- Next we encrypt the privkey with half the symkey by XOR'ing them together, a simple stream cipher. This avoids the use of AES in client code (slow in Javascript?, missing an initialization vector, plaintext length < AES block size of 128 bits) and should be pretty safe. Stream ciphers like RC4 are simply a random keystream XOR with the plaintext and are difficult to break, provided the random keystream is truly unpredictable and you never repeat the key. The trouble with stream ciphers then manifests when you have a large enough chunk of data to encode, then without a proper CPRNG like RC4 the keystream may repeat etc. and thus block ciphers under CBC become useful. Since we have a 32-byte private key and a 32-byte symkey to XOR together, this should not be the issue.
- We then use a MAC, specifically a HMAC-SHA1, to act as the password check against modification. We use the second half of the symkey as the secret. HMAC's are particularly designed for message authentication.
Alternatively (safer/more paranoid) you could use two salts to produce two 32-byte keys, one for the encryption, one for the authentication.
Excellent!!
Pixelglow, you really seem to know your stuff, are you a pro??
The PBKDF that I've been using isn't exactly PKCS#5 v1, it's actually OpenSSL's EVP_BytesToKey(). It's similar but will produce arbitrarily large key material. Otherwise, there certainly wouldn't be enough key material for an AES IV using SHA256.
Regardless, using PBKDF2 with an HMAC function would seem to be a very desirable change, and also appears to be very easy to get with OpenSSL.
Regarding pwcheck, the use of an HMAC function there with some additional key material also seems like the appropriate tool for the job, more so than my hacked-together mess. Can't really say no to that either.
Would you recommend HMAC-SHA1 over HMAC-SHA256?
Somebody smart said that a work is finished not when everything that can be added to it has been added, but when everything that can be removed has been removed. AES may fit into this category. However, other similar password-protection schemes, including bitcoin's built-in wallet encryption, also use AES for fixed-size private keys, and it's nerve-racking to replace it with XOR, even though it may be the correct thing to do.
Thank you very much!!