Use gpg
Introduction
gpg (more specific: GnuPG) can be used to encrypt/decrypt all sort of data, text including mails and binary files, for use of a recipient or for everyone who knows the passphrase (symmetric encryption). It is one of the most established standards for encryption and embedded into many applications, though this article focuses on direct use of gpg on the CLI.
Installation
Packages should be available for all distributions. The package is usually called "gnupg". If you do not know how to install packages, look here.
Usage
Creating a key
First, you should create an own key. This will allow you to sign data with your key, so other people can be sure it stems from you (if they trust the authenticity of your key) and it will allow people to encrypt data with your public key that only you, using your private key, can decrypt.
GPG stores all of its data under ~/.gnupg, though that will be created automatically. So just run:
gnupg --gen-key
Select "DSA and ElGamal" as key type and select a decent key length. If you are not concerned about how long your key will be in its ASCII representation (so you do not want to attach it to every mail or so), you should probably just use 4096.
Now you can select when the key will expire. This is up to you, however for a first test, you might want to create a key that expires after some days, so no one thinks that this is a permanent key though you do not use it any longer.
Confirm and enter you name, mail address and an optional comment. The mail address should be one that people will try to mail to later (if using the key for mailing) so that they get the key right off the key server.
Confirm another time and now choose a secure passphrase for the private key. This will protect your private key from illicit use, even if someone gets it (you should make sure it does not come this far!). Now just generate some entropy, surf the web, move the move etc., and your key should be generated and ready to use.
Perhaps you want to deploy your key to a key server now for your contacts to download. Read more about this below.
Exporting your key
When exporting a key, you most likely want a so called "ASCII armor". That means that no binary data is printed, but only alphanumeric characters. Of course this will make the output some bytes larger, but you will get data that can safely be printed everywhere like in a mail or on a homepage.
You get that ASCII armor by specifing -a as a parameter. Please note that this works for many other modes like encryption too and is very useful.
Export:
gpg --export -a [key-id] (get key id with gpg -k, leave out -a to get binary data)
Of course, you can redirect the output in a file and send this to your friends. Or just grab the ASCII armored output and inserted it via copy & paste somewhere.
Most likely you will also want your public key to be uploaded to a key server you everywhere can find it.
gpg --send-key 53CA1DC7
You can change the key server, per default subkeys.pgp.net should be used. But because your key will be synchronized between the key servers and spread to the other ones, that should not be needed.
Importing keys
Import is really simple, just call:
gpg --import
Now you can copy & paste a key you got and finish by closing the input (Ctrl + D).
Or you could just pipe a key contained in a file:
gpg --import < key
Import will process multiple keys at once and import public and private keys- whatever it will find!
Importing from a key server is also very simple and can be done interactively:
gpg --search-keys [mailaddress]
Now it requests a list of all available keys for that mail address from the key server and you can import the ones you want by just typing their number.
If you know the key id, you can import the key directly with:
gpg --recv-keys
Listing all known keys
This is the only operation that is a bit of confusingly on the command line, once you have collected a decent number of keys. You probably should use a GUI frontend for this.
Anyway, to list all your stored public keys:
gpg -k
To list your private keys:
gpg -K
Show the GPG fingerprints (useful for checking the identity of a key):
gpg --fingerprint
Encryption
To encrypt something, you need the public key of the recipient in your local key store. Then you can encrypt arbitrary data for him:
gpg -e -r [user] [file]
You can also give GPG the data on stdin:
something | gpg -e -r [user]
[user] is very flexible, you can specify the user in different ways. Perhaps the easiest is just to give the mail address.
Depending on what you want to do with the data, you can request encapsulation of the encrypted data in an ASCII armor (see above). Specify -a and you will get only printable (alpha-numeric) characters, at the price of a slightly larger output. If you do not redirect GnuPG's output to a file, you should really do this, otherwise you will get binary trash sent to your terminal.
Note: Encrypting something can be combined with signing it. More information on signing follows below.
Decryption
Decrypting required that you have the private key and the passphrase belonging to the private key.
Then run:
gpg -d [file]
Or again with stdin:
something | gpg -d
If your passphrase is not cached by gpg-agent, this will prompt for your passphrase.
Signing and verifying signs
Signing differs from encryption in that the cleartext is not scrambled. Even someone without GPG can still read your data, but someone with GPG is able to verify your signature (in contrast to encryption, which contains no signature) and verify that the message has been signed with your private key.
In general it is a good idea to combine encryption and signing, especially for mails.
To sign something, call:
gpg -s
But more useful is to create a detached sign with -b:
gpg -b
With a detached sign, your message is still readable without GPG and the signature can be transmitted after the message or even separately. This is the most common mode for signing mails, since not every recipient has GPG available.
Both commands will use your primary private key for signing, but you can change that behaviour but specifing the "local user" with -u to sign with another key. In any case, you will of course need to enter the private key passphrase to use it to sign something.
Like with encryption, you probably want to ASCII-armor the signing output.
To verify a sign:
gpg --verify
Again you need to provide the signed data on stdin or as a filename.
Symmetric encryption/decryption
Symmetric encryption requires no keys but just generates data with a symmetric cipher that can be decrypted by everyone who knows the secret passphrase.
gpg -c
Input is expected- as always- on stdin, after having specified the passphrase that will be able to decrypt the data.
Again: You probably want to generate ASCII-armored output.
For the experts: You can also combine symmetric and signing to provide a signed symmetric encrypted message. And you can even combine symmetric encryption and (asymmetric) key encryption to generate a message that can be either decrypted by having one of the recipient's private keys or by having the passphrase that has been used for the symmetric encryption! This comes in quite handy sometimes.
Revocation certificates
With a revocation certificate you are able to revoke the key that the certiciate was generated for, in case the key has been stolen or is simply not being used anymore. That ensures that no one continues to trust messages signed with the key or encrypts data for decryption with this key.
You generate a revocation certificate with --gen-revoke:
gpg --gen-revoke [key]
The key can again be specified in various ways, most common is to just use the mail address.
GnuPG now asks for the reason why the certiciate is being revoked and allows you to provide an additional description. After entering your passphrase you will then get your revocation certiciate.
It is a good advise, to create revocation certificates of all your private keys and store them in a safe (!) place.
Going further
- Setup gpg-agent which helps you by caching pass phrases, if you want.
- Install a graphical frontend like kgpg (good KDE frontend, albeit a bit buggy).
Comments
<comments />
I shall explore this idea further, thanks
--Anne Wilson 11:09, 18 October 2009 (CEST)