We’ll review here just a few often used commands to create and manage the keys:
Where is this used?
There are many places where GnuPG is used. We will now list some of the most common.
GPG is used to sign and encrypt emails. Most email clients implement it or provide a plugin:
- Outlook: needs GPG4Win.
- Thunderbird: Enigmail plugin
- Mail (Mac)
Each client has its own configuration and features. Mutt, for instance, can be configured to verify signatures automatically.
Package signing and checking
For Linux distributions, it is crucial to be able to verify that the software packages that users download are legitimate and coming from an authorized developer. We discuss a bit here the approaches used in Debian and RedHat (and their derivate distributions).
Apt is the package manager used in Debian systems. The process is the following:
- A Debian Developer (DD) signs the dsc file of the package she creates and uploads it.
- The FTPMasters (the team inside Debian that is responsible for package publication in the repositories) verify the DD’s signature, add the package to the mirrors and update the Release file with the checksum of the package.
- In a user’s machine, apt gets the Release and Release.gpg file, and verify the FPTMasters’ key.
- The apt client then uses the checksums to ensure the package’s authenticity
With RPM (RedHat’s package manager), the packages are signed with the distribution’s key. The rpm package then checks the signature.
In this image we can see how to check a package’s signature:
And here we can see how to list the keys that RPM knows about:
In git, GPG is used to verify the author of a commit. To use it, you need to have your gpg config in place. We can sign commits (-S) and tags (-s):
As with software packages in official distros, when we download software from the internet, we can ensure that it is really what the author published and not something modified. For example, this CPAN distribution contains a file called SIGNATURE that is signed and that contains the sha256 of all the files of the distribution. We can then generate the SHA256 of all the files and compare them to the signed file.
Evidently, you can also check the gpg software when you download it as a tar from the gnupg website.
Finally, we would like to point out some best practices regarding the use of GPG:
- Protect the keys with a password. If they get stolen, the thief will be able to impersonate you.
- Generate a revocation certificate along with the key. If you don’t do it and you lose the password or the key, there will be no way to revoke it.
- Back up the private key and the revokation certificate, preferably off-line.
- Set an expiration date. This can be changed afterwards if necessary but ensures that the key will expire at some point if we lose and we can’t revoke it.
- Consider the use of subkeys. For example, a key for work, a key to participate in a certain software project, etc.
- Sign only keys you know and check them beforehand.
- Create 4096-bit keys. 1K and 2K keys should not be considered anymore.
- The daemon haveged generates entropy in the system in the background, making it easier and faster to generate keys with 4K or more.
GPG is a great method, proven and trusted, to ensure integrity, confidentiality and authentication in the digital world. There are many uses for it, a lot of software supports it, and the basic usage of the command line tool is easy to learn. For developers and systems engineers it’s important to understand how it works and how to use it, to ensure trust in software, systems and communication. Additionally, since it’s been around for many years now, there’s a lot of documentation on it on the Internet.