Comments below...
-----Original Message----- From: Kaz Kylheku [mailto:kaz@kylheku.com] Sent: Thursday, September 05, 2013 6:40 PM To: Paul E. Jones Cc: aescrypt@lists.packetizer.com Subject: RE: [aescrypt] Usability suggestions for Windows app.
On 05.09.2013 15:04, Paul E. Jones wrote:
A useful behavior would be to have the option to rename the existing file, or to choose a different name for the newly created file. (Deletion should be deferred to the user, who should be using a secure shred program, at least for the plaintexts).
If the file is already encrypted or decrypted, why offer to create another version with a different name?
Ah, this is because it's not necessarily the same file.
The source file may have changed, and so the target plaintext or ciphertext may be out of date.
Right, but that's pretty poor practice. Except for the timestamp, one would not know which is the current version.
For instance, you may be working on a document and over the course, encrypt it more than once.
Yeah, I do that sometimes. In that case, I rename the encrypted files using a date in the name, like "20130905-Whatever.doc.aes". But, to keep the encrypted version and the plaintext version sitting in the same place does not have a lot of value. I tend to store the encrypted versions on an external drive or cloud storage. If I need to constantly keep a set of local files in encrypted state and change them frequently, AES Crypt is not the best tool for that. A better tool is TrueCrypt. TrueCrypt will create encrypted files that can be mapped as a drive (Windows) or mounted (Linux).
Keeping an out of date ciphertext could be handy since the prior version of the plaintext can be retrieved from it. If that isn't wanted, the program could optionally delete or simply overwrite it. (Insecure deletion of ciphertext doesn't raise an issue.)
On Windows, we do not over-write files. On Linux, we do. We get complaints both ways. :-) It's interesting to see reaction people have. By and large, people prefer the Windows behavior of not over-writing files, so we'll likely change the Linux code to behave similarly. What you want is a destructive write option. An "File Exists. Are you sure you want to replace it?" kind of prompt. That could be done.
Keeping an out of date plaintext allows the program to avoid implementing secure deletion. The file plain.txt is renamed to plain.txt.1 or whatever, and the user can deal with disposing of plain.txt.1.
Yeah, this is a risk. We've been asked to implement a secure wipe, but I've always felt it is better to use tools like shred. That said, some SSD drives cannot be securely wiped, anyway, even if you use a tool like that. File local file system security, it's better to use an encrypted volume. For storing files somewhere else, sending via email, etc. use of AES Crypt makes sense. I would not want to implement something where AES Crypt creates .1 files and such. Some people get confused by the very fact there is a .doc and .doc.aes. Creating a .doc.aes.1 would really cause confusion. Simplicity is important, I've learned. Paul