AES Crypt for Linux - Key File Support

[paulej]

AES Crypt for Linux now supports use of "key files". Basically, these are files that hold your password and can be used like this:

Code: Select all

tar -cvf - /home | aescrypt -e -k secret.key - >backup_files.tar.aes

To create a key file, just open Windows' notepad and create a one-line text file with your password inside and save it as "Unicode" or use the new utility provided as part of the aescrypt package:

Code: Select all

aescrypt_keygen -p apples secret.key

It is also possible to ask aescrypt_keygen to create a random password of a given length. Suppose you wish to create a key file with a 65 character password. To do that, you would enter this command:

Code: Select all

aescrypt_keygen -g 65 secret.key

This was a much-requested feature and one that I personally needed. So, here it is!

[Crypto-256]

Nice feature ! But this opens up some questions

Is it possible to use a keyfile AND password for the same encryption
example: keyfile (inside the keyfile is the password 1234)
and password abcd
which opens the next question
can I decrypt this encrypted file then with the use of only password ?
in this example, what is then the matching password for decryption, 1234abcd or is it then abcd1234 ??

this is an important thing, because now you only offer the use of a keyfile in your LINUX version
lets say I encrypt a file on linux with the use of ONLY keyfile
that encrypted file should be able to be decrypted on windows with your windows GUI version, but then
I have to use the password which is saved in the keyfile as content, as far as I understand

the point is, it would be very nice to introduce the possibility to use a keyfile also in the Windows GUI version

[paulej]

Don't get too excited thinking key files introduce a new level of security. They do not. In fact, a key file is nothing more than the password used to encrypt data. It's a plain text file encoded in UTF-16LE (a.k.a., "Unicode" per Windows Notepad). If anything, having those sitting around where somebody can access them is more dangerous than just using a password. That said, people (like me) who use AES Crypt for automatic backups and such already have the password sitting around where people could potentially get to it. I keep it protected on my Linux machine so that only I have access to the file, but before the password was in shell scripts. That was worse than having the password in a separate file, I think.

The reason for choosing plain text files as key files is that one can open up these files in notepad, and then copy paste the contents right into AES Crypt for Windows. Thus, the introduction of the "key file" means that we still retain interoperability between versions on different operating systems. This did not introduce a new kind of keying mechanism.

You suggested having a password to protect the key file. But, since the key file is nothing but the password, that request is like having a password to protect a password. It might make it easier when working with longer passwords (e.g., the password "apple" might be used to protect a key file that contains a 1024 character password). I can appreciate that, but I don't need it personally. And I'm not sure how to introduce that cleanly without creating confusion. Maybe if the key file ends with ".aes" then a -p flag is still needed? Then the -p is used to decrypt the .aes file in memory, etc. This needs some thought, but I don't have time to do it now. (I do have a string encryption library already done, so that could be used for this purpose.)

As for adding key file support in other releases, this is something that would be useful, but it is not a priority for me. However, if anyone wants to introduce that into the Windows code, we could merge it so that the functionality is there. I personally wanted this on Linux, since I use AES Crypt for backing up data to storage devices.

The fellow who wrote the Android app called "Crypt4All" has already introduced key file support in there. It works! It could serve as a useful model.

On Windows, though, AES Crypt stores no information in the registry (except what is needed to support the shell extension). There is no user data, no "key file" info, no password info, etc. If we introduced a key file concept in the Windows GUI code, we we would either have to have the user go manually select a file, manually enter the file name, or start adding information in the register. The latter I don't like too much, as I would prefer that no "hints" be left behind in the Windows registry. I also don't want to complicate the simple UI. This, too, needs thought.

[Crypto-256]

Ok, I understand, this is not a "2-Factor-Authentification", like, something you know (password) and something you have (keyfile). The keyfile in this case is only a password saved in an unencrypted keyfile and for some people this is even dangerous, keyfiles can get lost or stolen...

You are right, there is no new level of security when you put your whole (!!) password in the keyfile.
I did not suggest to encrypt the keyfile at all, it should stay unencrypted, because encrypting the keyfile would be too complicated and kill the best thing about AES Crypt, which is simplicity !
My question is more, not to put the "whole" pw in the keyfile, but to "split" the pw into two pieces, here a simple example
"whole" password is 70 characters, but lets say I am lazy, do not wanna type it all the time, so I type always characters number 1-20, those stay always in my brain, nowhere else
characters 21-70 I put in an unencrypted keyfile, no problem
so AES Crypt takes my typed 20 characters and then daisy-chains the content (50 characters) of the keyfile to it, so thats 70 characters
advantages? hmm, well, first is not having to type that much all the time
second, and maybe more important, if somebody steals my keyfile, he has still nothing, because he does
not know what is the first part of the PW

So my question was, is it possible to use AES Crypt with password and keyfile at the same time ?
Or does the use of a keyfile disable the possibility to type a part of the password ahead?

The point you made about the Windows GUI version, not adding any information in the registry, that is a
good and a clear advantage of this small programm, no need to change that, simplicity again wins !!
Even when a keyfile-support is introduced in the Windows GUI version, I strongly suggest the user can
and should choose the keyfile always manually, mostly for security reasons.
The UI is now small and simple, right, with the introduction of keyfile-capability it would suffer a little bit, for sure.

[paulej]

The option does not exist right now to split a password into two pieces, putting only part in a file. I would not recommend that, either. Having the password in a file introduces risk, but no more risk than what people are doing today with putting the password in environment variables or in shell scripts. However, people (including me) use AES Crypt in automated processing where there is no human available to enter a password.

In my own use, I'm not worried that the password is in a file, since the file is protected. Further, if somebody had access to the key file, they have access to all of the data the key is protecting, anyway. The only way to avoid that is to manually enter a password, and I cannot do that when the backups run in the early morning hours What's more important to me is that when a backup leaves my physical control, that backup file is secured. And I never put keys in the clear with the backup files that go on external media, obviously.

Encrypting the key file actually isn't so hard. In fact, I could auto-detect whether the key file is an AES file or not (since AES files start with 'AES' and UTF-16 do not), not relying on the file name itself. As the file is read in, if it appears that the file is encrypted, I could easily decrypt it. That's not hard. The question is value. Anybody want that? So, one might have a 512-character password that is encrypted with a 20 character password. Thus, the overall protection is lower *if* somebody is able to get the key file in their hand, but it's significantly better protection if the attacker only has the encrypted file and no key file.

Should I put that on the "to do" list? It will take work -- and time I don't have right now. But, if people want that, I'll add it to the list. One of these years that list might get done ...

[Crypto-256]

Ok, I understand, you only can use a keyfile OR a password. In the case of automated backups the use of a
keyfile is good, but every user is then responsible to protect this keyfile.
An implementation of such an automated protection into AES Crypt is not necessary in my opinion.
Sure, it would be convinient, but also confusing for many users and complicating things a little bit.

If I have to protect the keyfile, I do it manually, I can encrypt it myself with AES Crypt, of course with another password, this password can even be shorter, everything is better than leave it completly unprotected.
Or put the keyfile in an encrypted Zip-file or encrypted 7z-file or a truecrypt container, whatever, many other choices there.
Just putting the keyfile unencrypted on an usb-drive (or any other media) is a bad choice.

[paulej]

Here's a simple shell script that can serve as a wrapper around an encrypted key file so that you can encrypt the complex key file with a simpler password.

Code: Select all

#/bin/bash
#
# encrypt
#
# Encrypt a file using AES Crypt and a key file that is protected
# with a passphrase.  If successful, the error code returned will
# be 0. Any non-zero error code indicates an error.
#
# Usage: encrypt <key file> <password> <file> [ <file> ... ]
#

if [ $# -lt 3 ] ; then
    echo "usage: encrypt <key file> <password> <file> [ <file> ... ]"
    exit 255
fi

# Get the key file and password from the command-line
KEYFILE=$1; shift
PASSWORD=$1; shift
PLAINTEXTKEYFILE=$KEYFILE.$$

# Set a trap to ensure we clean up
trap "{ if [ -f $PLAINTEXTKEYFILE ] ; then echo Removing plaintext key file; rm -f $PLAINTEXTKEYFILE; fi; }" EXIT

# Decrypt the key file
echo Attemping to decrypt key file
aescrypt -d -p "$PASSWORD" -o "$PLAINTEXTKEYFILE" $KEYFILE || exit

# Encrypt the target files(s)
echo Encrypting target file(s)
aescrypt -e -k $PLAINTEXTKEYFILE $*

To use it, create a key file we call "mykey.key". Then use AES Crypt to encrypt the key file with a simple password like "apple". This produces an encrypted key file "keykey.key.aes".

Then you can encrypt a file called "foo.txt" like this:

Code: Select all

encrypt mykey.key.aes apple foo.txt

The plaintext version of the key file will exists on disk temporarily, so one should still take precautions to ensure that the directory storing keys is not accessible by those who should not have access.

Paul

[johnmcloud]

When you add this feature also to the command line version of Windows?
Thanks

[paulej]

I don't know. I'd very much like to do that, but need to find some time to do it. Right now, I'm busy with other stuff, one thing being a project that needed this in the Linux version. It should not be to hard to port it over.

Paul

[johnmcloud]

Thanks Paul, i know you do the most of the work on the software.
I have a little curiosity...it's possible to crypt-encrypt a partition on-the-fly instead of a file ( like truecrypt ) or is impossible based on the code development?