Alice wants to encrypt her data. She is not comfortable with using only a password. While she prefers to use a properly random crypto key, she isn't confident she can protect the key file from theft or loss. So she wants to use both.
Bob proposes that she derive her encryption key EK from her password P and input key IK (the key Alice keeps in a file) as follows:
- EK = HKDF( IK + PBKDF2(P) )
In which + is concatenation, PBKDF2 uses plenty of iterations, and both KDFs use SHA-256 and null salts.
Alice is interested but not yet sold on Bob's proposal. She has two questions:
Wouldn't it be better to use a salt with the KDFs? If so, where to keep it?
Since she needs to back up the file containing IK in a couple of safe places, shouldn't it be encrypted and have an HMAC?
Bob scratches his beard, mutters "good questions". Eventually he says that these two extra steps add complexity to the process that needs to be justified, and asks, "What, if anything, do they add to the security of your data?"
Given Alice's requirements, how would you answer Bob's question question?
(Or is Bob's proposal faulty? (Or perhaps Alice's requirements do not make sense?))
The story continues...
Bob is trying to taking Alice' worries seriously because he knows her government's reputation for brutality and suppression of dissent. So he posts a question to a social Q&A web site called "Information Security" and get's a very through answer from Tom Leek for which is is very grateful. From that answer Bob gleans:
Encrypting IK using another key derived from P does little to make it harder for Alice' wicked government to obtain her plain-text data. Decryption of Alice's data requires IK, P and the encrypted data either way. Adding encryption and authentication could make matters worse if it is not implemented correctly, for example, by exposing side channels.
Using null salt input to PBKDF2 means using an empty string as the salt. This is not the best choice. He decides to use a random value for salt and, for operational convenience, to keep it in the same file as IK.
Authentication of the key file is valuable, even though its encryption is not.
So Bob's revised proposal involves adding an HMAC to IK in the key file beside the salt. Thus the key file looks like:
- salt + HMAC + IK
In which HMAC is computed over IK using an authentication key derived from P but different from EK.