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 DATAFILEDespite his earlier comments about the web of trust, Koch also recommended the following commands as being particularly useful for the aftermath of key-signing parties. This command will list the keys in a file without actually importing them:
gpg --import-options show-only --import FILEOnce the keys to be signed have been imported, the following command will sign a key without all of the usual interaction that key signing requires, so it is ideal for building a key-signing script:
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.]
Index entries for this article | |
---|---|
Security | GNU Privacy Guard (GPG) |
GuestArticles | Yates, Tom |
Conference | Kernel Recipes/2017 |
(Log in to post comments)
An update on GnuPG
Posted Oct 10, 2017 16:44 UTC (Tue) by droundy (subscriber, #4559) [Link]
An update on GnuPG
Posted Oct 10, 2017 18:55 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link]
Shall you trust this key right away? Shall you trust this mail address right away? Shall you trust this person right away? I doubt that anyone will send confidential information to an unknown mail address. Before you can send confidential information you will setup a relationship to that person and only over time you may get an idea whether it is okay to send information which are not intended for the public. TOFU can support you here.
The less common case is that you need to write to a well known address, say The Intercept, which has a public track record suitable for your needs. Here you can get the key and manually (i.e. local key signature) mark that key as valid, for example by looking for publications with the fingerprint of the key (or well, the WoT). That needs a lot of due diligence at both ends on how to do it properly without accidentally leaking information - checking the fingerprint is only a minor part.
An update on GnuPG
Posted Oct 10, 2017 18:59 UTC (Tue) by dd9jn (✭ supporter ✭, #4459) [Link]
- wk@gnupg.org.
An update on GnuPG
Posted Oct 10, 2017 23:18 UTC (Tue) by wa (subscriber, #107586) [Link]
1 - Can't trust be a continuous variable rather than binary, where trust is built up over time? Once this is in place it might invite mechanisms for verifying against an increase in trust over time. TOFU would then increase trust from 0 to some base value <1.
2 - If there is a peer2peer network WoT verification could be automated. This could be a network of email contacts and presumably could be automated.
Does that make sense?
An update on GnuPG
Posted Oct 11, 2017 3:36 UTC (Wed) by gdt (subscriber, #6284) [Link]
Presumably you mean "built up with use". But it's a different measure: just because I'm regularly mislead doesn't mean that I'm not mislead.
The converse situation happens regularly. If you've ever been to a keysigning you'll have lots of highly-trusted keys (you've seen their passport, driver's licence, a mutual friend of a decade vouched for them, and no one in a room of a hundred people said they were someone else), but you might never correspond with them. Why should this lack of correspondence lower their trust score?
> If there is a peer2peer network WoT verification could be automated
Doesn't really help, as there's no reason for one p2p peer to be more trusted than another. So all the peers could announce differing public keys and you'd have no notion as to which is the genuine key.
The point of using the e-mail provider is that they can be more trusted than some other server, as the email service has additional means to associate that public key with the email address (eg, the public key was uploaded using the userid+password for the mail service).
An update on GnuPG
Posted Oct 11, 2017 4:39 UTC (Wed) by jaymzh (subscriber, #57150) [Link]
Instead, please use something established. I recommend PIUS (https://github.com/jaymzh/pius/) (disclaimer: I wrote and maintain it) or caff (https://wiki.debian.org/caff) (not written by me).
An update on GnuPG
Posted Oct 11, 2017 7:52 UTC (Wed) by robert_s (subscriber, #42402) [Link]
An interesting new approach is that of keybase.io, though I personally see hope in a hybrid approach where the web of trust is just one of many factors that can help to increase trust in a key. So here's hoping keybase.io get round to finally adding (supplemental) web of trust support.
An update on GnuPG
Posted Oct 11, 2017 10:40 UTC (Wed) by Sesse (subscriber, #53779) [Link]
An update on GnuPG
Posted Oct 12, 2017 13:34 UTC (Thu) by zuki (subscriber, #41808) [Link]
Pfff. That's supposed to be the new nice interface?
What about something that one can actually type from memory, like
> gpg --show FILE
?
An update on GnuPG
Posted Oct 12, 2017 15:00 UTC (Thu) by amarao (guest, #87073) [Link]
An update on GnuPG
Posted Oct 12, 2017 21:59 UTC (Thu) by debacle (subscriber, #7114) [Link]
An update on GnuPG
Posted Oct 13, 2017 12:37 UTC (Fri) by dd9jn (✭ supporter ✭, #4459) [Link]
An update on GnuPG
Posted Oct 15, 2017 21:27 UTC (Sun) by debacle (subscriber, #7114) [Link]
An update on GnuPG
Posted Oct 19, 2017 6:13 UTC (Thu) by eduard.munteanu (guest, #66641) [Link]
The chain of trust may need to be bootstrapped via less secure means, but there are better ways than giving up security completely (which is what TOFU does). I'd much rather get the keys via HTTPS, even from third parties. Cloning a Github repo over HTTPS is much more acceptable than using plain HTTP, even if you don't trust SSL/TLS that much.
I've found it that, In practice, it boils down to ignorance or laziness. Many open source projects fail to deliver keys and software securelly because whoever designed the distribution system does not understand or downplays crypto. The cost of a proper setup is minimal, you can even get SSL/TLS certificates for free these days, yet it's simply not implemented. And it makes the difference between trusting a pool of core people and trusting everybody along your Internet connection. A proper setup increases the difficulty of attacks enormously in exchange for a tiny cost, so there's no good excuse.
Web Key Directory and service design
Posted Nov 7, 2017 8:21 UTC (Tue) by ber (subscriber, #2142) [Link]
https://wiki.gnupg.org/WKD points to details about how WKD/WKS is designed and what this means for users, email providers and mail users agent developers.
https://wiki.gnupg.org/EasyGpg2016/AutomatedEncryption is a draft documents with ideas how encryption can be enabled by default in many situations.
(Note: I'm one of the authors and maintainers of these documents.)