epidata-list@lists.umanitoba.ca wrote:
The reason for placing the encrypted key encrypted in the header is:
- There must be a place to compare the entered password with the true
one
Otherwise the decryption cannot work. You could argue that if a false key was provided, then nonsense would be returned and it would be up to the user to see that contents of an encrypted field was garbage. I would feel that was a dangerous situation, since if the user saved the record again, then the wrong key would be applied to garbage giving "double" garbage and no way to retrieve data.
OK, fair enough, but in that case, you should "salt" the password before encrypting it. Usual practice is to use a one-way hash (SHA-1 is safe) of the salt+password, rather than encrypting the password with itself using teh same cipher as the rest of the data - the reason being that a recursively-encrypted string makes a known-ciphertext attack theoretically easier. There are various methods of chosing a salt - which is 2 to 4 random bytes.
Another approach would be to save the key in a different file than the rec file header, but your arguments would apply equally to that.
Certainly I can assure: The idea was NOT to provide a backdoor in case the user forgets their password. There is no way for EpiData crew or others to retrieve a forgotten passkey
So the core of the reasoning has been: We rely on the "non-breakability" of the AES/Rijndael encryption principle and we need to know if the user uses the correct key - otherwise data could be lost.
Yes, but unless you "salt" the password before encrypting it, you make dictionary attacks (or brute force attacks) against the password rather easy. Every byte of salt you add before encrypting (or better, hashing) the password makes a dictionary or brute-force attack 256 times harder.
Just a suggestion.
Tim C