I wish to create a system wherein I store encrypted data.
Users can access this data if they have the key. If they give a wrong key, they don't get access at all. If they give the right key, they get the data, and they may modify that data.
One idea I came up with is to store the bcrypt of the key, a salt, and AES-encrypted data using a PBKDF2 with the salt, and a high iteration number.
Getting the data would follow this process:
- Get the key from the user.
- Get the bcrypt of that key.
- If the bcrypt doesn't match, deny access.
- Get the
PBKDF2of the key with the salt. - Use that
PBKDF2to decrypt the data. - Give the data to the user through a secure channel (beyond this design).
The system should make it hard to get the data, even if you have access to the raw, encrypted, data.
My design seems to achieve that goal, but I have differential cryptanalysis concerns around the fact that the key is both encrypted with bcrypt and with a PBKDF2 encrypting AES. Could cross-referencing the bcrypt and the raw, AES-encrypted data make it easier to break the key? Are there known issues with this kind of designs?
Is there a simpler way?
Obviously I can't get rid of the bcrypt part, because any key would decrypt the AES data (although the result would be gibberish). I can't use bcrypt as the key for AES, because the key would be stored along with the encrypted data, which defeats the purpose of encrypting.
