[aescrypt] Another potentially widely useful UI feature.
Paul E. Jones
paulej at packetizer.com
Fri Sep 6 00:03:11 EDT 2013
> 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
> 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:
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
> 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.
More information about the aescrypt