What's best practise to GPG single large file with keyfile on USB stick?
 

Hi,

I have a large file I would like to encrypt with GPG and move onto the cloud or public storage, etc. so it can't be read and or tampered with without be knowing when I decrypt it.

I normally use:
$ gpg -c desktop2011.img
Passphrase: ****

and this creates a desktop2011.img.gpg file which works fine.

But what I want is no passphrase and just have a small .key file I can safely store on a USB stick.
What's the best practice for doing this with GPG?

One more thing...
I actually have a few (notebook1.img, notebook2.img) files too. I want all these encrypted with different keys on the USB stick, I don't want one master key for all of them if this makes sense.

I would use openssl for this.

The way you apply this depends on your security model, but basically you encrypt things doing:

1- Create a random key.
openssl rand -base64 32 > keyfile

2- Encrypt the thing using openssl:
openssl enc -aes-256-cbc -pass file:keyfile -in clear_file -out encrypted_file

This is a dirty way, of course. You can have a passphrase stored in hex, and an IV (Initialization Vector) saved in another file, which would be more "elegant" that having just a plain-text keyfile with a random generated password.

Remember that the keyfiles are vulnerable if they are not physically secured. If you have them in a USB drive and it gets stolen, they have the key as it is. Read the manuals and use your brain, having keyfiles around is good because you avoid keyloggers and the like, but it is bad because the "passphrase" can be stolen.

Thanks BlackRider, I have used openssl for a similar thing in the past.

But still wondering the best practices for GPG doing this as GPG is more suited for large files (and has builtin compression etc).

The -c flag with gpg will ask for a passphrase, which is what you are saying you don't want. Normally, one can just use the -e flag instead. This way the only pass phrase will be the one on the private key that will be needed when you decrypt. You can also create a signature and even a detached ascii signature that you can use to verify the file integrity using your public key. See the following link for details on the command flags: http://www.gnupg.org/documentation/manpage.en.html

If you don't want to go to the trouble of creating a public/private key-pair for the purpose then you can use the --passphrase-file or even --passphrase-fd option along with the '-c' option to avoid having to enter the passphrase manually

I use this approach to copy & encrypt a second copy of my daily user-backup incremental tar files to a usbkey

e.g.

Obviously anyone who can read the script will be able to see the passphrase, but for my usage case that is not an issue as it's only intended to protect the data on the usbkey and anyone who can read the script (700 root:root) can read the originals anyway.

There's also a "--passphrase string" option that'll let you put the passphrase directly on the command line but I wouldn't recommend that one as it'll be exposed on a "ps -ef".

GazL,

This is what I was thinking. But to have a passphrase that is something like 1000 chars long (like a key).

What a waste. I think such a big key would have its half end unused for cryptographic purposes. An AES-256-CBC algorithm needs a key of 256 bits only, everything above that would be wasted. A 1000 character key is over 5000 bits.

Of course, I am not an expert, nor have I looked so deeply in the OpenSSL implementation. Should this be false, please tell it to us.

This was for the passphrase I was referring to. But if I could store the raw 256bit key in a .key file instead that would be better.

Well, you've been given ideas about how to go about things with openssl (the simplest way IMHO) and with gpg's symmetric encryption .... so I'll give a quick primer on using gpg with keys, as it was originally intended.

While I don't particularly think it's necessary to use different keys to encrypt your different files, it is possible, so I'll show one way.

So what this does is create 3 new directories in the "USB" directory you specify and then tells gpg to generate new public-private keypairs using each directory (in turn) as it's home directory (instead of the traditional ~/.gnupg). It also sets each directory's config file to use its first key as its default-recipient (so that you don't have to type in -r or --recipient).

Regarding --gen-key:
For key type, choose the first choice -- "RSA and RSA (default)".
For key size, you're welcome to jack it up to 4096, since I get the feeling you might be a bit paranoid.
Name, email, & comment are only important if you're going to be distributing the public half of this keypair to others, so they can encrypt things to you; for this explanation, it doesn't matter what you type.

Once that's done, you're ready to use them. But first, a note: when starting out with gpg, I found it was great to run it with -v or -vv (verbose) in order to get a better idea of what was happening, so I recommend adding that to your command-lines (or add 'verbose' to gpg.conf).

You end up with three files, encrypted with three different keys. In order to decrypt them, you'll need to use the same homedir setting (or you could import all the keys into one keyring).

Don't worry if you get mixed up about which keys you used for which files; it's simple enough to figure out, as long as you still have the keys. Obviously, if you only have 3, at most you have to give it 3 tries, but if you have more ...
PS: If you give up your requirement of always storing keys on usb, the best gui gpg-key-management tool I've seen is a gnome-app called seahorse and it would be simple enough to use to create a few different keys. As a bonus, if you keep the keys on your computer instead of in a usb drive, you could install seahorse-plugins and use nautilus to encrypt/decrypt them via its right-click menu.

Thanks ryran.
I will try seahorse and have a look if it can work for me. Looks good.