10 tips for effective use of OpenPGP with GnuPG

Using a private encryption system based on the OpenPGP standard can provide a great improvement to the security of your sensitive data. To maximize the value of that improvement, however, you need to make sure your OpenPGP system itself is secured against the efforts of malicious security crackers.

The following tips assume you are using GnuPG on a free/libre/open source UNIX-like system, such as FreeBSD or Debian GNU/Linux. They also assume you are minimally familiar with the workings of such a system so that an explanation of how the ls command works is unnecessary (for instance).

Protect your private keyring file. This is the file used to store your private encryption keys. By default, this file is located at ~/.gnupg/secring.gpg. At minimum, you should ensure that its file permissions are set to 600 (using the chmod command if necessary). If a malicious security cracker cannot access your private keyring file directly, he or she cannot decrypt or digitally sign as you unless he or she has both access to the system on which the keyring file is located and your passphrase.

Protect your passphrase. You need to ensure that you do not forget this passphrase (especially if you use your GnuPG key to encrypt and protect other passwords), but you also need to make sure it does not fall into the hands of a malicious security cracker. A good, strong passphrase is monumentally difficult to crack — so difficult that, at present levels of technology, it is effectively impossible. Thus, without your passphrase, a malicious security cracker cannot encrypt, decrypt, or digitally sign as you unless he or she has direct access to your private keyring file. Even then, the ability to make use of it is in doubt because GnuPG stores it as encrypted data (thus the need for the passphrase).

Use a strong passphrase. A passphrase that just uses a single English language word is trivial to crack. A passphrase that uses a famous quotation is not much better. A passphrases that uses letter substitutions, such as p4ssw0rd instead of password, is easily cracked as well. Spaces, special (non-alphanumeric) characters, and long character sequences unrecognizable as comprising words in any way, are all important parts of a strong passphrase. The reason people use passphrases instead of 128-bit keys is that they are easier to remember — but the reason people usually try to guess a passphrase rather than trying to guess the 128-bit key it protects is that the passphrase is usually easier to guess. Make it as difficult to guess as possible without ensuring you forget the passphrase.

Limit the number of machines on which you store copies of your private key. Ideally, you should only have the key on one machine that is not connected to a network and copy files that need to be encrypted or decrypted back and forth between that machine and others only via physical media. This improves your ability to protect both the key and your passphrase significantly. On the other hand, it is extremely impractical for many people. For most purposes, simply limiting it to one machine on which you ensure great care is taken to maintain a “secure enough” environment is good enough, but the degree of security you require for your private key is a decision entirely in your own hands. The fewer machines on which you store your key (preferably one), however, the better. In fact, the absolute best you could do would be to store your key on zero computers — instead, keep it on a USB mass storage device, a floppy, or some other removable storage media, and only access it from a computer that is not connected to any network. The impracticality of this approach for most people is significant, however, and it is almost never employed these days.

If you must transfer your private key from one machine to another, doing so via physical media such as a floppy, USB mass storage device, or CD-R, is far preferable to transfering via network. Wireless networks are a particularly bad idea for transfer of a private key, in general. Limit the exposure of even encrypted private keys to any networks because doing so ensures that a malicious security cracker would not only need to compromise your network to copy your private key (or keyring file) but would need to specifically compromise the computer where that key is stored.

You may want to have more than one private key. If you have need of a key in an environment you do not entirely trust — such as on a workstation at your place of employment, where others’ indiscretions may lead to reduced security on the network — you should not trust your most important private data there. This may, for many people, mean maintaining two separate private keys (and their attendant public keys).

When you generate your private keys (your “keypair”), you should also create a revocation certificate. This can be done with a simple command, where name is replaced with the name under which your key was created: gpg --output revoke.asc --gen-revoke 'name'. The revocation certificate should be stored on physical media such as a floppy disk or CD-R, preferably somewhere secure such as a safe or safety deposit box, in case your key is compromised and needs to be revoked.

Set an expiration date for your encryption subkey. Normally, when creating your keypair using GnuPG, you have one each of a DSA master signing key and an ElGamal encryption subkey. The former is used for signing documents. The latter is used to decrypt files that have been encrypted using your public key. It is typically the case that you do not want your master signing key to expire; this key is intended to act as your “fingerprint,” if you will — a verifiable personal identification tool. The latter, however, may be set to expire to improve the security provided by GnuPG. If it changes periodically, your encryption subkey is even more difficult to crack and use, because an old key that is cracked does not allow anyone to access any future documents. It would only allow a malicious security cracker to decrypt and read documents that were encrypted prior to the expiration of the old key.

To make maximum use of the OpenPGP standard as a means of providing privacy and security of communications, you should learn about the concept of a web of trust, and be very careful with how you make use of this concept to improve the convenience of private encrypted communications so that the security of those communications is not compromised. The key (pun not intended) point is to recognize that a relationship should be established and verified between a given public key and the real, physical person it is meant to represent and identify. Depending on how extensively you use an OpenPGP system, it may be impractical to personally identify each individual with whom you may wish to establish private, secure communications, and a “web of trust” is a mechanism for providing the identification you need without having to personally visit every single one of them.

Talk to others about improving privacy and security via GnuPG and other OpenPGP compliant systems. It only helps secure a path of communication if the person on the other end is also using it, after all.