4

I am using the PKCS#5 standard to generate a key using a random and unique salt and the user`s password in input. Consider this key as the "encryption" key.

The "encryption" key is used to encrypt a random AES key. Each users have an AES key associated to their profile.

So, a user`s profile will contains this informations:

--> password hash for authentication purpose.

--> salt used in the PKCS#5 algo. (From the PKCS#5 V2.0 documentation, we know that this information needs no protection).

--> the encrypted AES key generated randomly and encrypted with the "encryption" key generated by the PKCS#5 algo with the salt and the user`s password

I was asking myself if it is dangerous to be in possession of the password`s hash, the salt and the encrypted AES key IN THE SAME TIME. I am 99.9% sure that this is not a problem, but can it facilitates the work of an attacker being in possession of all those details?

ir01
  • 383
  • 1
  • 4
  • 13
Normand Bedard
  • 2,625
  • 2
  • 19
  • 22

1 Answers1

3

The password hash also needs to use a salt, otherwise dictionary attacks are possible and two users who happen to pick the same password will have the same hashed password stored in the DB.

I would suggest this: Just use PKCS#5 twice; once to generate the hashed password (which you store in the clear), and once to generate the encryption key (which you do not).

Make sure the salts are large, random, and independent, and then there will be no detectable relationship between the password hash and the encryption key. That is what the salt is for, after all.

[update, to elaborate a bit]

Pick two salts s1 and s2. Make sure each is at least 64 bits, random, and independent.

Use the password + s1 as input to a PKCS#5 HMAC on the empty string. This is the "hashed password".

Use the password + s2 as input to a PKCS#5 encryption scheme to encrypt the actual data.

Store the hashed password, s1, and s2 in the clear in the database. Done.

Nemo
  • 70,042
  • 10
  • 116
  • 153