RFC 5959 specifies the encrypted storage of private keys based on PBKDF2-HMAC-SHA-256 and AES encryption (in ECB mode).

Is there a particular reason AES is used, instead of simply XORing the key material with the PBKDF2 output? Is it simply to make storage of long keys faster, because a long PBKDF2 output takes long to derive?

When storing a short key, e.g. a 256-bit ECC private key, is there a good reason to use AES or is the XOR with a single PBKDF2 (or other KDF) output block sufficient?


Your description of how RFC 5959 works isn't quite right. It is not quite correct to state that RFC 5959 encrypts using AES in ECB mode.

A correct statement is: if the plaintext is exactly 128 bits, then use ECB mode, otherwise use a non-trivial mode of operation found in RFC 3394. In the former case, ECB mode is fine, since it's just a single block of data. In the latter case, RFC 5959 says to use the AES Key Wrap with Padding algorithm as defined in RFC 5649. This algorithm specified in Section 4 of RFC 5649. Section 4.1 of RFC 5649 specifies the key wrap, and explains how it works. It says to use the scheme of Section 2.2.1 of RFC 3394, if the input is not exactly 128 bits (which is the case that will occur if you are storing a 256-bit ECC private key.)

Anyway, a key wrap algorithm (such as specified in RFC 5959) is much better than simple XOR. (If there was no salt, a simple XOR would be insecure if you used it to protect two different private keys with the same passphrase: compromise of one private key would enable an attacker to learn the other private key (since it's just a two-time pad).) More seriously, a simple XOR is malleable and thus would allow related-key attacks on the underlying scheme, as Ricky Demer explains; if the underlying scheme (e.g., ECC decryption) is vulnerable to related-key attacks, this would be a problem.

Better to use a key wrap algorithm. Key wrap algorithms are designed specifically for storing private keys in encrypted form, and there's a reason they use something other than simple XOR.

| improve this answer | |
  • $\begingroup$ "passphrase" $\: \mapsto \:$ "passphrase and salt" $\;\;\;\;$ $\endgroup$ – user991 Jul 7 '14 at 11:39
  • $\begingroup$ @D.W. No need to thank me… you’re more than welcome. (kill my heads-up comment accordingly) $\endgroup$ – e-sushi Jul 8 '14 at 0:10

Yes. $\:$ "simply XORing" is obviously malleable, which may allow related-key attacks.

"When storing a short key, e.g. a 256-bit ECC private key," the "good reason to use AES" is
that "the XOR with a single PBKDF2 (or other KDF) output block" is not necessarily sufficient,
since an adversary might also have changed the stored public key.

| improve this answer | |
  • $\begingroup$ Isn't AES in ECB mode somewhat malleable as well? You can swap two blocks or change only one block in a long key. Not as much control as with XOR, but wouldn't a MAC be better if that's the attack scenario? $\endgroup$ – otus Jun 20 '14 at 6:29
  • $\begingroup$ If the (padded) plaintext is longer than one block, then a MAC would probably $\hspace{1.67 in}$ be useful for the attack scenario I described. $\;$ $\endgroup$ – user991 Jun 20 '14 at 6:41
  • $\begingroup$ So if malleability was the reason for choosing a block cipher, wouldn't they have specified either another AES mode or required the use of a MAC? The "main" use case is multi-block RSA keys, after all. $\endgroup$ – otus Jun 22 '14 at 15:12
  • $\begingroup$ They probably would have. $\;$ $\endgroup$ – user991 Jun 22 '14 at 20:41
  • 1
    $\begingroup$ @otus, RFC 5959 only uses AES in ECB mode if the plaintext is exactly 128 bits long. That is not malleable (not in any useful way that would enable related-key attacks). $\endgroup$ – D.W. Jul 2 '14 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.