[aescrypt] Usability suggestions for Windows app.

[Paul E. Jones]

Comments below...

> -----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
> 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