1
$\begingroup$

I'm developing a kind of secret vault server application. The basic principle is similar to DPAPI where each secret will have its own unique random KEY/IV pair and and that KEY/IV pair will be encrypted with a PBKDF2 derived key from user password.

I have doubts as to how properly handle key derivation and authentication. This is what I came up with:

User registration:

  1. User supplies username and password
  2. Generate random salt using CPRNG. Store the salt with user record.
  3. Derive a KEY and IV from password using PBKDF2
  4. Generate a random master KEY/IV pair and encrypt this master pair with generated KEY/IV pair from step 3 using AES-GCM. Store encrypted KEY and encrypted IV separately in two records, store TAG in third record.

User verification:

  1. User supplies username and password
  2. Use stored salt and supplied password to derive a KEY and IV
  3. Use derived KEY/IV pair to try to decrypt master key. If verification fails, authentication fails and user is not let in

All encryption is done on server side. Communication is secured with TLS but this is not the topic nor is the sizes of key, IV or salt. Let's assume I will choose the sizes correctly. The scheme I choose to use must protect the data even if database is stolen.

My questions about this are:

  1. Is it safe to generate IV along with KEY from PBKDF2 when using and storing salt for each user or should IV also be randomly generated and stored along with salt? When generating IV from PBKDF2 I'm basically choosing for it to be part of the key, ie a secret. Using a sufficiently large salt per user would guarantee that no two generated KEY/IV pairs exist even if users have same passwords.
  2. Should randomly generated master KEY pair be stored with both KEY and IV encrypted or should IV be stored in plain text?
  3. If you store both encrypted, it is safe to store them in two separate records or should they be encrypted together (concatenated) and stored in a single record? This is regarding IV reuse since two records are now encrypted with same KEY/IV pair.

Thank you!

$\endgroup$
1
$\begingroup$
  1. Is it safe to generate IV along with KEY from PBKDF2 when using and storing salt for each user or should IV also be randomly generated and stored along with salt? When generating IV from PBKDF2 I'm basically choosing for it to be part of the key, ie a secret. Using a sufficiently large salt per user would guarantee that no two generated KEY/IV pairs exist even if users have same passwords.

Sure thing, but I would recommend to use a KBKDF such as HKDF on the output of PBKDF2 instead of generating a larger output. The reason is that PBKDF2 doesn't handle large output well. That is: output larger than the underlying hash size.

  1. Should randomly generated master KEY pair be stored with both KEY and IV encrypted or should IV be stored in plain text?

Inconsequential. The IV can be stored in plaintext as well. I'd recommend this as key wrapping is often thought as a specific routine, and it won't include the IV. Furthermore, you probably need more than one IV (see below).

  1. If you store both encrypted, it is safe to store them in two separate records or should they be encrypted together (concatenated) and stored in a single record? This is regarding IV reuse since two records are now encrypted with same KEY/IV pair.

You need to create a fresh IV for each record that you encrypt. If you have trouble storing the IV then you should consider Format Preserving Encryption (FPE).

$\endgroup$
  • $\begingroup$ Tnx for answering! I'm using one key/iv pair per thing encrypted be it another key or a secret so I'm always generating random KEY/IV pairs (not deriving them). The only place where I derive the key/iv pair is for user master key encryption. I made a crucial mistake in encrypting keys since I was encrypting a key and iv separately with the same key/iv pair and storing them separately. I will change this so either I will be storing IVs in plain text or will concatenate IV and key and encrypt the whole pair in single operation thus eliminating IV reuse. $\endgroup$ – Marko Vodopija May 16 '16 at 15:36

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.