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