I'm developing an application that will use public key authentication to contact some webservice. So the user has his keypair on his computer, and I want that file to be encrypted using AES with a key derived from a user's password.

I'm wondering if I'm using relatively "safe" parameters and way of writing the file.

Here are the PBKDF2 and AES parameters:

  • PBKDF2 Iterations : 1024
  • PBKDF2 Hash function : SHA256
  • PBFDF2 Salt size : 256 bits
  • PBKDF2 Derived key size : 256 bits
  • AES Cipher mode : CFB

Here is how the file is written:

  • Salt (Hex encoded)
  • Return line
  • IV (Hex encoded)
  • Return line
  • Encrypted file content (Hex encoded, encrypted using AES in CFB mode and the key derived from the user's password)

Maybe what's missing here is a HMAC (with SHA256, for example) to "guarantee" that the file hasn't been tampered with. Here's how probably I'd append it to the file, after "Encrypted file content":

  • Return line
  • HMAC-SHA256 with the content's encryption key

Thanks in advance.

  • 1
    $\begingroup$ 1024 iterations is very low. If you can afford the performance hit, use a larger value. On a desktop computer you should be able to afford a million iterations. $\endgroup$ Oct 9, 2013 at 10:09
  • $\begingroup$ increase iterations, reduce salt size. You do not need to encrypt the public key, but it should be authenticated. Possibly use OCB or GCM for 1 pass authenticated encryption. $\endgroup$ Oct 9, 2013 at 10:18
  • 2
    $\begingroup$ "HMAC-SHA256 with the content's encryption key" - naughty. Never use the same key for two different crypto primitives. Upon completion of your PBKDF2 rounds, perform a final round, but ask for 512 bits of output. Use the first 256 bits for the encryption key, and the rest for the HMAC key. More info here. As mentioned, if it's available, authenticated encryption such as CCM, EAX, GCM or OCB is also a good option. $\endgroup$
    – hunter
    Oct 9, 2013 at 12:41
  • 1
    $\begingroup$ @hunter one has to be careful about that. If one directly requests more than the natural size from PBKDF2 it can increase the cost for the defender but not for the attacker. Personally I like HKDF-Expand for this step. $\endgroup$ Oct 9, 2013 at 13:42
  • 2
    $\begingroup$ I would also store the number of iterations in the file (that was used for this particular file), in case you will change it later on. Later files will be encrypted with higher number of iterations, but the older files can still be decrypted. For that matter other non-secret parameters can be stored for backward compatibility as well, such as PBKDF2 hash function used etc. $\endgroup$ Dec 19, 2013 at 17:22

1 Answer 1


As this question is still on the list of "questions without answers", I'll quickly answer it (Basically repeating all of the above comments).

  1. Increase iteration count to something larger (1 Million?)
  2. You don't want to attach your HMAC of the plain-text after the contents. Rather authenticate either the ciphertext or (even better) use CCM/EAX/GCM mode.
  3. Store the PBKDF's params in the header of the file.
  4. Don't use PBKDF2 if possible. Rather use scrypt (best choice currently, for the next weeks), bcrypt (if no other option) or some of the PHC finalists.
  • 1
    $\begingroup$ I'd stay with PBKDF2, bcrypt and scrypt for several more years. I don't consider the review the candidates received during the PHC competition sufficient to be really confident in their security. $\endgroup$ Apr 12, 2015 at 9:48

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.