How about a way to verify one's knowledge of a key without doing the actual bulk decryption.
AES Crypt already does that. The key/password decrypts a block of data that contains the "real" initialization vector and key used to do the bulk encryption. So, if you enter the wrong password 4 a 4GB file, it will not have to decrypt the entire 4GB file.
Suppose I have an .aes file and I would like to answer the question "Does this file have the password that I think it has?" without actually decrypting the file.
One has to do some decryption to get that answer, but it's fairly minimal. Some have argued against the approach, since one can test passwords faster. But, given that a strong password/key (i.e., one that's pretty random and long) would mean an attacker would have to try a very large number of passwords. A 256-bit key would mean there are 1.18 x 10^77 different keys to try.
Furthermore, there could be an optional checkbox on this UI to actually do bulk-decrypt the file to verify its integrity, but without creating an output file.
More options = more complexity and people get confused. A much easier way to see if a file is valid or not is to do an SHA-1 or SHA-256 hash over the file. I do precisely that when I archive files in cloud storage. I encrypt files, record the hash (before and after encryption), and then archive the file. When I pull the file from storage, I can verify the hash is what I had recorded in my local database. Now, that's a little more complex. But, you could do the same thing. Just produce hashes of encrypted files. Here are some SHA-1 tools to do that: http://www.packetizer.com/security/sha1/ It would also be possible to store the hash in the header of the .aes file. There is a TAG/VALUE section that is intended for storing metadata about the file. An SHA-1 hash value over the file (excluding the TAG/VALUE data) would be interesting. It could be inserted even after the encryption is done. But, I would not put that in AES Crypt. AES Crypt has to work in streaming mode where data comes in, is encrypted, and ciphertext goes out. But, one could introduce an "aes_integrity" utility to insert hashes. Or, just store the values somewhere. For example, have a file called "foo.txt.aes" and one called "foo.txt.sha1.txt" that contains the hash string.
These tools could be used, for instance, by Bob to confirm to Alice that a file (which is to be processed by Bob at some later date) was correctly received.
That really would require either a hash computation or decrypting the file. A problem with hashes for this case is that you don't know if the hash data was manipulated in transit. One solution might be to encrypt the hash file (foo.txt.sha1.txt) and send that, too. Then Bob could decrypt the hash file quickly (since it's very short) and then compute a hash over the encrypted data file see that it matches. Some of these things you want to do are interesting, but can easily be done with scripts at the Linux shell prompt. Adding this directly into AES Crypt just makes the program heavy. It's good to keep it simple and focused. Paul