There are many guides on the web for setting up GPG keys. Most of the one I have come across are outdated, or simply incorrect. This is an attempt to right those wrongs.

What is GPG?

GPG (GnuPG) is a hybrid-encryption software program. GPG is a free-software replacement for Symantec’s PGP cryptographic software suite. The GnuPG software is compliant with RFC 4880, the IETF standards-track specification of OpenPGP. Hybrid because it uses a combination of conventional symmetric-key cryptography for speed, and public-key cryptography for secure key exchange. The key exchange method is called Diffie-Hellman and, typically by using the recipient’s public key to encrypt a session key which is used only once. This mode of operation is part of the OpenPGP standard and has been part of PGP from its first version.

What is it for?

The business-level answer to this question is that we usually use GPG to send secrets between team members in a distributed or remote work environment. E.g. if the CEO needs to give me the company credit card details to sign the company up for a corporate GitHub account, I will:

  • Send the CEO instructions on how to install gpg and configure it for the best security
  • Send the CEO instructions on how to make their own public and private keys
  • Send the CEO my public key, and request theirs in return
  • Send the CEO instructions on how to install secure email client and insert their keys
  • Ask the CEO to make an encrypted email to me containing the secret credit card information that I need

It may seem like a lot of work, but let’s all remember that email is all plain text in flight and plain text at rest on the server, and so many companies have lost so much IP and more from having their email hacked or leaked on-line.

BASIC RULE do not send secrets in plain text email

BASIC TRUTH it doesn’t matter if Google Mail has a little padlock in the browser, the body text of the email is not encrypted, the email is stored as a .txt file on someone else’s computer. And if you work in a large organization, it is likely that the IT team subverted the https connection anyway to make sure you are not stealing company secrets. Do not trust email.

There is a more thorough technical-level answer to the question that involves encrypted storage of company secrets, encrypted code repositories, encrypted backups, and signed code commits. But, for now, let’s stick to the email use case.

Are there any downsides to using GPG for email encryption?

Yes! Basically if your email is fully encrypted then you lose the ability to search in your email contents - because it is all encrypted and we only unwrap one message at a time.

Why is this a bad thing?

Well, basically people then realize that the email title is not encrypted and start putting more and more useful and search-able information into the email subject line, and that can compromise the systems that you are trying to protect by encrypting the information.

Consider an encrypted email between senior systems administrators that had a title “Secret log server logbot@logbot.company.com port 5060 password inside”. I mean, sure we don’t know that password, it is in the email body that is encrypted, but we have just been given the user, machine DNS and log system port in the title. A crackers job just became a lot simpler.

The full GPG installation and configuration guide

This post got really long, so I have broken it into more manageable parts:

  1. Installing and Configuring GPG
  2. Create new GPG master and subkeys
  3. Exchanging GPG public keys
  4. Send/Receive GnuPG Emails on MacOS

References