Using PBKDF2 with AES and SHA2

Question

I use the following inputs to encrypt using AES:

• UserPassword (plain text)
• SecretKey
• RandomIV

I use the following inputs to encrypt using SHA512:

• UserPassword (plain text)
• RandomSalt

I'd like to enhance both encryption methods above by using key derivation functionality. I will use the .NET Rfc2898DeriveBytes Class which requires the following:

• MasterPassword
• Salt
• Iterations

---

For AES:

Should I use the AES SecretKey for the PBKDF MasterPassword param? I currently generate an AES RandomIV and store the IV+CIPHER in the DB, when upgrading to use PBKDF is it correct to do the following:

• Do not generate an AES RandomIV
• Generate a new random Salt for the PBKDF
• Use the first x bits of the DerivedKey as the AES SecretKey
• Use the second x bits of the DerivedKey as the AES RandomIV
• Store the 'new random Salt'+CipherText in the DB
• Both the AES Encrypt & Decrypt methods will have a PBKDF Salt param rather than an AES IV param (ignore the fact that they are both just byte[]'s)

For SHA512:

• Is it correct to use the UserPassword (plaintext) for the PBKDF MasterPassword param (instead of securely storing a secret MasterPassword like AES)?

• Should I use the SHA512 RandomSalt as the PBKDF Salt?

• When calling the SHA.computehash method, should only the DerivedKey by hased, or should the salt be appended to the DK?

• How many bytes of the DerivedKey should be encrypted, 64?

Answer 1

Lets get some ground rules out of the way. SHA512 isn't an encryption function, its a hash function. PBKDF2 (Assuming you are using the newer 2nd variant...) isn't a hash function or an encryption function, its a way of using a hash function and is commonly used to generate the key for an block cipher or stream cipher.

In most situations I don't think PBKDF2 is very helpful. The problem being that if you use a hash function like SHA512 with PBKDF2 then an attacker can still use an FPGA or GPU cluster. Bcrypt is more difficult to attack using these technologies than PBKDF2+SHA512, regardless of the number of rounds you choose to use with PBKDF2. You could use PBKDF2+Bcrypt, and that is not a bad choice, however I still think that scrypt is a better choice because both CPU usage and memory usage are variable, where as with PBKDF2 only CPU usage and the hash function used is variable.

Up next your IV design:

Use the first x bits of the DerivedKey as the AES SecretKey
Use the second x bits of the DerivedKey as the AES RandomIV

Ok, so based on this design I would conclude you have no idea what an IV is or why its used. So the point of an IV is that at no point will you encrypt the same message with the same key+iv. Your proposed design is in clear violation of CWE-329. The attacker can know the IV, that doesn't matter, but it must always be random. There are a few reasons why, and I suggest picking up a copy of Practical Cryptography because it has an entire chapter devoted to this topic.

Also CBC mode isn't authenticated, I am a fan of OMAC1 mode.