views:

75

answers:

2

Hi there, I'm in the process of designing a web application that will require the storage of GPG keys in an encrypted format in a database.

I'm planning on storing the user's password in a bCrypt hash in the database. What I would like to be able to do is to use that bCrypt to authenticate the user then use the combination of the stored bCrypt hash and another hash of the password to encrypt and decrypt the GPG keys.

My question is whether I can do this without reducing the security of the password? I was thinking I may be able to use something like an HMAC-SHA256 of a static string using the password and a salt as the secret key.

Is there a better way to do this that I haven't thought of?

Thanks

A: 

If you're always going to decrypt the GPG key then you could hold a known value encrypted with the key and use that to verify the user password (i.e. if the correct user password has been entered then the decrypted GPG key will decrypt the stored data to the known value).

Use a standard key derivation algorithm to generate your key from your password, your crypto library should include one.

Patrick
EDIT: i miss understood your answer the on the first, and the second, read. This may work though it would require more CPU load to attempt doing a decrypt of two items each time a user attempted a log in.
Nevins
A: 

Consider using PBKDF2 (from PKCS #5). It takes as inputs as passphrase, a salt, and an iteration count. The iteration count specifies how many times the passphrase should be repeatedly hashed; using a large number for this (1000 to 10000 is common) helps make password guessing attacks harder. The salt causes different uses of the same passphrase to create different keys.

Due to the design of PBKDF2, it would be very difficult to guess a hash generated with one salt even if you knew the hash that was generated by the same passphrase for a different salt.

PBKDF2 is already implemented and available out of the box in most any crypto library of note. For instance it is available as PKCS5_PBKDF2_HMAC_SHA1 in OpenSSL (header evp.h).

Jack Lloyd