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?


2 Answers 2


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.

  • $\begingroup$ "passphrase" $\: \mapsto \:$ "passphrase and salt" $\;\;\;\;$ $\endgroup$
    – user991
    Jul 7, 2014 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, 2014 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.

  • $\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, 2014 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, 2014 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, 2014 at 15:12
  • $\begingroup$ They probably would have. $\;$ $\endgroup$
    – user991
    Jun 22, 2014 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, 2014 at 23:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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