PBKDF2 hash over PBKDF2 key derivation

Question

Imagine an app where any user provides a username and a password. This password is used to generate a 'strong' encryption key (for AES encryption) with the PBDKF2 key derivation algorithm. This encryption key is used to encrypt user data in a database.

Now, to identify a user and grant him access to his encrypted data, I used to hash its encryption key with the "SHA-512" algorithm and then compare it with the stored hashed key. I want to upgrade my strategy and better protect my app against brute-force attacks.

Since PBDKF2 is also a hash algorithm, my two questions are :

1. is it safe to use PBDKF2 to hash (and then store) an encryption key that has been generated by the same PBDKF2 algorithm (schematically PBDKF2.hash(PBDKF2.derivate(password)))?
2. is it equally safe to store the encryption key encrypted by itself (schematically AES.encrypt(input = key, key = key) ) instead of the key hash?

Answer 1

Hashing a derived key is not a security issue because cryptographic hashes are one way. There are two ways people could attack the derived key.

1. Guess a password, process it using PBKDF2, SHA-512 hash the result and see if it matches
2. Guess a derived key (128 to 256 bits), SHA-512 hash it and see if it matches

The amount of work performed per guess with method 2 is much lower, but the probability of being successful within n guesses is only n / 2¹²⁸. Since the total amount of work is n times the work-per-guess, method 1 is always less work in practice. (Method 2 is never practical because brute forcing 128-bit or larger keys isn't currently possible.)

I estimate that typical "good" user chosen passwords have 30-40 bit strength. So you can expect them to be guessed within 2⁴⁰ guesses instead of 2¹²⁸. You would only "break even" if PBKDF2 were made to cost 2⁸⁸ times SHA-512. No user, legitimate or not, would be able to login if that were the case. It would just take too long.

(Not that "breaking even" matters in practice. Method 2 is already out of reach for real world adversaries so it's a strategy that no one is going to bother with. People's passwords are the weakest link in the chain. Not an algorithm as reliable as SHA-512.)

---

Another issue makes it possible to bypass the second level of PBKDF2 brute-force protection. Hashing the derived key and comparing it to the stored hash is not the only way for a hacker to determine if they have the correct derived key.

If they have access to ciphertext, then they instead could perform trial decryption to get a good idea of whether or not they have the correct key. It's not even required to decrypt all the ciphertext. A few bytes should suffice.

Alternatively, they could use the message authentication algorithm. (Encryption without authentication is a really bad idea. You do use an authenticated-encryption mode, right?)

Any place where key material is derived from a user's password provides a potential pathway a hacker can use to verify whether a guessed password is correct. Using any one of these avenues gets the person trying to crack a password the same answer. so they are going to use whatever option is easiest.

This is another weakest link in the chain situation. Whether you use PBKDF2/SHA-512 or PBKDF2/PBKDF2, expect that your level of brute-force protection is only as strong as the first layer of PBKDF2.

PBKDF2/SHA-512 can actually be made stronger than PBKDF2/PBKDF2. If you have only one second to budget to verifying a password, then it is preferable to put nearly 100% of that one second into the first PBKDF2.

Using SHA-512 for the second-level check lets you do this because its run time will be near-instantaneous compared to PBKDF2. (But again, a 128-bit key (or stronger) is not brute-force-able because the actual cost of SHA-512 is non-zero and 2¹²⁸ SHA-512 evaluations adds up.)

If you instead let the first layer of PBKDF2 run for 0.5 seconds then ran the second layer for 0.5 seconds, then you'd really only have half the brute force protection of what you could otherwise afford.

Answer 2

What are you trying to achieve here? Utilize a user's password for (1) authentication/login as well as a (2) key to encrypt their data? If so, then consider what password managers typically do - I see as bearing similarities with what you're proposing. Here are the operations cannibalized from an answer to a different question:

client_rounds = 5000 // iteration count may be user-defined
encryption_key = PBKDF2(HMAC-SHA256, password, salt, client_rounds) // unlocks your data
auth_hash = sha256(encryption_key) // sent to the server for authentication
server_rounds = 100000
server_key = PBKDF2(HMAC-SHA256, auth_hash, server_salt, server_rounds) // server can use this to do additional encryption

Full algorithm:
PBKDF2(HMAC-SHA256, sha256(PBKDF2(HMAC-SHA256, password, client_salt, client_rounds)), server_salt, server_rounds)

is it safe to use PBDKF2 to hash (and then store) an encryption key that has been generated by the same PBDKF2 algorithm (schematically PBDKF2.hash(PBDKF2.derivate(password)))?

Yes, it is safe, but using PBKDF2 for hashing is not the appropriate algorithm because hash functions are expected to be fast, whereas PBKDF2 is intentionally designed to be slow for key derivation.

Since you are already applying PBKDF2 to the password that is sufficient defense against brute force attacks - increase the iterations as needed.

Then follow up by hashing the derived key, which is also stored instead of the actual key/password.

is it equally safe to store the encryption key encrypted by itself (schematically AES.encrypt(input = key, key = key) ) instead of the key hash?

No, not safe. Encrypting keys are hard to do right - you will want to research key wrapping, starting with NIST's key wrap recommendations. Hashing is a much better approach.