An update on GnuPG

Please consider subscribing to LWN

Subscriptions are the lifeblood of LWN.net. If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

The GNU Privacy Guard (GnuPG) is one of the fundamental tools that allows a distributed group to have trust in its communications. Werner Koch, lead developer of GnuPG, spoke about it at Kernel Recipes: what's in the new 2.2 version, when older versions will reach their end of life, and how development will proceed going forward. He also spoke at some length on the issue of best-practice key management and how GnuPG is evolving to assist.

It is less than three years since attention was focused on the perilous position of GnuPG; because of systematic failure of the community to fund its development, Koch was considering packing it all in. The Snowden revelations persuaded him to keep going a little longer, then in the wake of Heartbleed there was a resurgent interest in funding the things we all rely on. Heartbleed led to the founding of the Core Infrastructure Initiative (CII). A grant from CII joined commitments from several companies and other organizations and an upsurge in community funding has put GnuPG on a more secure footing going forward.

GnuPG 2.1 has been around for nearly three years, so it's time for something new: GnuPG 2.2 was released in August, with the bug-fix 2.2.1 version following in mid-September. GnuPG 2.0 will reach its end of life around the end of 2017. Support for PGP-2 keys has been removed from GnuPG 2.2 because of their age and their heavy use of the MD5 hash. That said, the venerable GnuPG 1.4 will continue to be maintained for its portability to pre-POSIX systems and because people with data encrypted with old PGP-2 keys will want some way to decrypt that data going forward. The GnuPG 2.3 development branch will be opened, to go forward hand-in-hand with proposed improvements to the underlying standard including a SHA-256-based fingerprint and new default algorithms.

Koch then moved into Elliptic Curve Cryptography (ECC), which he discussed at some length. RSA, he said, is not likely to stay secure for much longer without really large keys. Support for 4096-bit RSA keys has been in GnuPG for some time, but Koch contends that real security will require 16Kb keys; that makes keys, fingerprints, and signatures all unusably long, particularly for embedded devices and hardware security modules (HSMs).

So instead he's moving toward ECC ciphers, which are well-researched — more so than RSA, according to Koch. Instead of key size, ECC applications speak of using different curves, and while for RSA the same implementation can be used for many key sizes, with ECC each curve needs to be implemented separately. Some of these curves (Koch named the NIST curves required for NSA Suite B) have a bad reputation, as described in a talk [PDF] by Daniel J. Bernstein and Tanja Lange, for example. Some, including the German government, would prefer the Brainpool curves [PDF] but these, too, are over a decade old. RFC 7748 is moving us toward the current best-available curves, he said, including Curve25519, Curve448 (called by its author the Goldilocks curve because of a deep connection to the golden ratio, φ), and some variants; GnuPG will be using these curves going forward.

Koch showed examples of digital signatures of comparable security, one made with RSA-4096 and one with Ed25519; the latter is about a third of the length of the former. Performance of these new ECC curves is also pretty good. HSM timing data showed that RSA is about 60 times slower than Ed25519 for signing. In response to a question from the audience, Koch agreed that since the RSA timings were from one HSM and the Ed25519 timings from another it is difficult to compare them directly. Nevertheless, the timings from the RSA HSM showed that a doubling of the key length increased the time required to sign nearly six-fold, and the time for verification even more. The timings from the Ed25519 HSM were agreeably small (all sub-50ms).

Security of the private key is clearly much on Koch's mind at the moment. GnuPG 2.2 mandates the use of gpg-agent because private key handling has moved entirely out of gpg itself and into the agent. Most of the complex stuff that gpg does with keys is unknown by the agent as gpg-agent only performs private-key operations (which, incidentally, it can also do for SSH). This enables some clever tricks such as running gpg on a remote server, perhaps to sign a large tarball, but running gpg-agent locally on a desktop so that all private key material and operations are handled locally. Such an architecture also lends itself to the use of HSMs to securely store private key material.

Historically, using HSMs has meant smartcards, but Koch noted that even though these implement an open standard they do it with proprietary code, leaving us no current choice but to evaluate the vendors for trustworthiness, and then choose a product. Though this is what Koch himself does now, he'd like more freedom, and is working to bring to market the Gnuk token. It is based on an STM32 microcontroller, running a fully-free stack and is designed to be the HSM of choice for GnuPG, but bringing it to the European market is proving troublesome. CE certification isn't too bad, he said, but WEEE compliance is proving painful; he's working with Kernel Concepts to try to turn the Gnuk token into something you can buy for 30ドル-35 in its FLOSS-Shop store.

The management of public keys is much on his mind as well. If you want to be completely sure that a key belongs to a particular person, you get a copy of their public key directly from them, or you seek a copy signed by a trusted intermediary. If you don't do that, then right now your only option is the public keyservers. Koch notes we have a good network of these, but it's hard to have any kind of trust in keys on the public servers, absent a fortuitous intermediary signature on such a key or a key fingerprint provided out-of-band by your correspondent. If you search for him on the public servers, Koch said, you get back two keys, one of which is a deliberate fake (I tried on the MIT keyserver, and found three equally plausible-looking keys).

The problem is systemic: the web of trust, he feels, is inherently broken. It is only explicable to geeks, and not to all of them, it publishes a global social graph, because signatures on keys imply physical meetings on known dates, and it doesn't scale. His preference for general public key handling is Trust On First Use (TOFU). It's easy to explain (we've all been doing it with SSH for years), and it doesn't require any central key-distribution authority, the existence of which he feels would be a betrayal of one of the core PGP principles. It isn't yet GnuPG's default model for trust, but it may become so in the future.

If you accept that TOFU is a pragmatically acceptable practice, particularly for securely communicating with new correspondents, then can we do better than the public keyservers for getting their keys? Koch feels that the right place for on-demand key distribution is the email provider. Your email provider has some idea who you are, and you have some kind of contractual relationship with them, however tenuous. In turn, their control over your email address's domain name is reasonably easy to establish through pre-existing channels such as DNS (especially if it's all signed with DNSSEC). So your provider is in the right position to run a server that serves keys, but only for domain names for which they provide email, which preserves the decentralization that Koch finds so desirable. The nascent Web Key Service (WKS) protocol provides a mechanism for provisioning, populating, and querying such a server, and it is supported in GnuPG from 2.1.15 onward. There exist some nice HOWTOs for both setting up the server, and using the service with one privacy-aware MUA. Readers keen to experiment with this, particularly at the key-publication end, will probably need to nag their email provider if they are not themselves lucky enough to control their email domain.

Quite a few of Koch's slides were given over to the new, scripting-friendly --quick-* options, but many of these were present in GnuPG 2.1 and so have been covered here before. A couple of his newer examples are worthy of closer examination. At the moment, if you have someone's public key and want to encrypt data using it, you must import it into your keyring, then encrypt. But often the only time I intend to use a particular key is for this one encryption; I'm not going to use it again and I don't want it rattling around in my keyring forever. The use of the -f FILE_WITH_KEY option to read a key from a file without adding it to a local keyring allows me to handle this gracefully, with:

 gpg -f FILE_WITH_KEY -e DATAFILE

 gpg --import-options show-only --import FILE

 gpg --quick-sign-key FINGERPRINT [NAMES]

In summary, Koch said that GnuPG 2.2 brings modern algorithms, better scriptability, and support for automated key discovery based on a correspondent's email address (if we talk to our providers). He added a couple of warnings (that Debian has a fairly old version, and that Ubuntu LTS has 2.1.11 where some things, including encryption using ECC keys, are broken).

The talk was followed by the traditional charity auction, which this year was in support of GnuPG. Michael Kerrisk, Aurélien Rougemont, Sylvain Baubeau, and Eric Leblond each donated a large sum of money in exchange for a 1.5l bottle of beer which all the speakers had signed. Peter Senna Tschudin went well into three figures for the 2l ornate flask of beer, also signed. All five deserve mention in dispatches; this will have to do.

[We would like to thank LWN's travel sponsor, The Linux Foundation, for assistance with travel funding for Kernel Recipes.]

Note: you can avoid this step in the future by logging into your LWN account.