[aescrypt] Usability suggestions for Windows app.
Paul E. Jones
paulej at packetizer.com
Thu Sep 5 21:06:00 EDT 2013
> -----Original Message-----
> From: Kaz Kylheku [mailto:kaz at kylheku.com]
> Sent: Thursday, September 05, 2013 6:40 PM
> To: Paul E. Jones
> Cc: aescrypt at 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
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.
More information about the aescrypt