[EpiData-list] Encrypted fields in EpiData

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Tue Jan 4 04:30:19 CST 2005


epidata-list at lists.umanitoba.ca wrote:
> The reason for placing the encrypted key encrypted in the header is:
> 1. 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



More information about the EpiData-list mailing list