Why yet another Gnupg howto: to have an uptodate "best of" collection with special focus on secure use. Because in many cases cryptography is not weak due to mathematical issues in the algorithm or implementation but simply due to wrong use of the tools.

Before generating a key, think about a good location to store it. A network file space, a shared machine and similar might not be a good location. Better is local harddisk (think about secure backup), encrypted harddisk or hardware token. And of course, a machine having e-mail and webclients, office tools and perhaps many other programs installed is a much easier target, so perhaps do not use the same (virtual) machine doing all the dirty stuff.

Paranoia: Also consider other ways to access your key: a backup system copying it from the harddisk, system crash diagnosis tools (e.g. apport) copying it to a bug report, person having access to your unencrypted harddisk once or means to steal it and replace it with identically looking device just airing out what you type ...

A good key is not only long enough (bits), it should also have a hard to guess passphrase. As machines are very fast at guessing passwords, make their lives harder by requiring them to hash the password not only once before trying it but thousand times. Thus in event of a stolen private key, unlocking is much harder.

gpg --gen-key --s2k-mode 3 --s2k-count 65011712

By using --s2k-mode 3, the passphrase is hashed and salted, so you also do not have to worry about rainbow tables, see RFC4880. For parameters, RSA/RSA and 4096 bits should do it. There is dispute over best expiration time settings. I think infinite expiration time is OK, as a) a stolen private key can be used to decrypt any old communication regardless of expiration time b) for stolen key you have to air out the revocation immediately, not waiting for month/years to let the key expire and c) unused key should be revoked immediately.

At first, generate a revocation signature so that you can revoke your key even when you lost access to your private key, e.g. by forgetting the passphrase, deleting the key without backup, ....

gpg --output RevocationSignature.txt --gen-revoke [your userid]

Store the signature in a place not too hard to access, e.g. some local storage media or even a printout of the base64 signature - in worst case having to retype it from paper for 30 minutes, which may be one of the smaller problems when you really have lost access to your private key. An attacker stealing the revocation signature, even when he recognizes it, will most likely not use it as he has only little benefit from it. See also [1].

Paranoia: Separate the signature from those locations, where you use/process your private key usually: ransomware may encrypt your disk, both the key and the revocation signature, fire may take your home and your backups, ...

Now you may want to upload your PUBLIC key to keyservers. Search engines are your friend.

You may now sign your messages immediately, e.g. using gpg on command line or using tools like Enigmail for Mozilla mail clients, which is much more convenient. While having your private key in a secure location is quite easy with command line signing - just copy unsigned/signed data to/from the machine with the key - using Enigmail et al. will cause you to somehow grant access to the private key to a machine with huge attack surface: your desktop with internet connectivity and a plentitude of not very secure software installed. There are some options:

• a) not caring about that
• b) using a separate virtual machine for gnupg use which has the minimum on software installed to perform secured communication only. No surfing, no gameplay, no other communication.
• c) use remote gnupg invocation helpers like the (very primitive and badly written) RemoteGnupg
• d) combine b and c

To send encrypted messages to others, you need their public key. You may download them from keyservers or acquire them from other sources. FIXME: no refs yet, use search engine. The problem is to verify, that you really got the key of the person you wanted to have. Options:

• a) use the web of trust to establish link from already known and trusted key, e.g. from a person physically met already, to the key you need.
• b) if a is impossible download the key from other sources. If possible, do not rely on the short key-ID (0xNNNNNNNN), it can be easily choosen when generating a key (see here) and also not the 64-bit variant (too hard for me to fake but I assume no challenge at all for a good mathematician). Take your time to compare the full key fingerprint (hash).

Paranoia: When important, try to contact the key holder and verify the fingerprint via separate channel. If not possible, download using different internet links, machines accessing different sources, e.g. when target person posted on mailing lists, get posts with signatures from different lists via HTTPS.

As stated in a conference talk, NSA likes encrypted e-mail as it contains an easily trackable fingerprint of the person sending it, even when the cannot decrypt it (FIXME: reference). If decryption is needed, locating the person using captured communication is not too hard, decryption using remote access trojans, waterboarding et al. is technically not very complex. To make it a little harder, avoid generating encrypted messages that contain the key-ID of the encryption key embedded in the message. This key-ID is just a hint to the decryption software to know, which private key to try first. If it is missing, it has to try all of them. Make sure to have the --throw-keyids option included in all your encryption procedures, e.g. via command line but also as Enigmail advanced option.