[EpiData-list] Encrypted fields in EpiData

epidata-list at lists.umanitoba.ca epidata-list at lists.umanitoba.ca
Tue Jan 4 03:57:20 CST 2005


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.

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.


As a comparison, e.g. the password mechanism provided by WINZIP or
Access is not reliable, there are programs on internet which will guess
millions of passwords in few seconds for these - and find the one used.


regards 

Jens Lauritsen
Initiator and coordinator of EpiData




More information about the EpiData-list mailing list