Future directions for PGP

Back in October, LWN reported on a talk about the state of the GNU Privacy Guard (GnuPG) project, an asymmetric public-key encryption and signing tool that had been almost abandoned by its lead developer due to lack of resources before receiving a significant infusion of funding and community attention. GnuPG 2 has brought about a number of changes and improvements but, at the same time, several efforts are underway to significantly change the way GnuPG and OpenPGP are used. This article will look at the current state of GnuPG and the OpenPGP web of trust, as compared to new implementations of the OpenPGP standard and other trust systems.

GnuPG produces encrypted files, signed messages, and other types of artifacts that comply to a common standard called OpenPGP, described in RFC 4880. OpenPGP is derived from the Pretty Good Privacy (PGP) commercial software project (since acquired by Symantec) and today is almost synonymous with the GnuPG implementation, but the possibility exists for independent implementations of the standard that interoperate with each other. Unfortunately, RFC 4880 was released in 2007 and a new standard has not been published since then. In the meantime, several extensions have been added to GnuPG without broader standardization, and a 2017 IETF working group formed to update RFC 4880 ultimately shut down due to lack of interest.

GnuPG 2 is a significantly heavier-weight software package than previous GnuPG versions. A major example of this change in architecture is GnuPG 2's complete reliance on the use of the separate gpg-agent daemon for private-key operations. While isolating private-key access within its own process enables improvements to security and functionality, it also adds complexity.

In the wake of the Heartbleed vulnerability in OpenSSL, a great deal of scrutiny has been directed toward the maintainability of complex and long-lived open-source projects. GnuPG does not rely on OpenSSL for its cryptographic implementation, instead it uses its own independent implementation: Libgcrypt. This leads to the question of whether GnuPG's cryptographic implementation is susceptible to the same kinds of problems that OpenSSL has had; indeed the concern may be larger in the case of GnuPG.

Despite the release of Libgcrypt as an independent library, it has not seen substantial use outside of GnuPG itself, preventing it benefiting from more thorough security review as OpenSSL has had. This concern is not purely theoretical, as multiple vulnerabilities in GnuPG and Libgcrypt were published in 2017, including side-channel leaks in the RSA implementation and ECC implementations that were each previously known issues in other software projects.

NetPGP

In response to concerns about the maintainability of GnuPG, two projects have been launched to create independent, interoperable implementations. The first is NetPGP, produced by the NetBSD project. NetPGP was first developed [PDF] by Alistair Crooks in 2009, and has since reached a fairly stable state. It is available under the BSD license and is intended for use both as a user-facing command-line tool (netpgp) and as a library (libnetpgp). Its main downside is a limited feature set compared to the larger GnuPG.

NetPGP is based on the OpenPGP SDK implementation by Ben Laurie and Rachel Willmer, which is in turn based on OpenSSL. NetPGP's command-line tools are significantly simplified compared to GnuPG's. For example, the netpgp manual page describes fewer than a dozen major options and only 24 in total, as compared to gpg with well over one hundred, some of which accept many subcommands. Major GnuPG features missing from netpgp include interacting with key servers, key signing and trust management, and subkey management. NetPGP's library interface is similarly simplified, with only one header file and about a dozen key function prototypes.

NetPGP's capabilities include the basic functions of a PGP implementation: encryption, decryption, signing, and verifying. It also includes a basic key-management tool, netpgpkeys, which operates on a keyring stored in the same format as used by GnuPG. This shared keyring format makes it easy to use NetPGP alongside GnuPG, such as when NetPGP is embedded in other tools.

NetPGP was developed primarily with an eye toward having a BSD-licensed PGP implementation for embedding in BSD tools, since GnuPG is licensed under the GPLv3. NetPGP's simple feature set and library interface reflect this purpose, particularly in the inclusion of the separate netpgpverify command that only performs signature verification and is perfect for use in shell scripts. NetPGP is useful but does not make up a full competitor to GnuPG.

NeoPG

To replicate the features of GnuPG, it's easiest to start from GnuPG, and that's exactly what the NeoPG project has recently done. Developer Marcus Brinkmann launched NeoPG based on a fork of the GnuPG codebase with the goals of improved maintainability and ease of use.

While NeoPG started with the GnuPG codebase, it is quickly diverging. Two primary goals of the project are a switch to C++ and a replacement of the GnuPG cryptography implementation with the Botan C++ encryption library. NeoPG further introduces a number of engineering measures to improve code quality, including unit testing, continuous integration, and the use of a fuzzer for stability testing.

NeoPG also varies from GnuPG in its architecture. NeoPG will continue to use a single-process design as GnuPG 1.x did, rather than depending on separate daemons for some functionality. This is not a simple or uncontroversial decision, as isolation of sensitive operations into separate processes does have security advantages. In a message to the oss-security mailing list, Brinkmann explained the decision:

NeoPG also aims to improve usability of both the command-line tools and the library interface. The library interface will be significantly simplified, while the command-line interface will use a Git-style subcommand structure. As for the underlying cryptography, Botan is a fairly popular C++ library which has been audited using funding from the German government and is under active development.

NeoPG is still in an early development stage and many intended features have not yet been implemented. Brinkmann has already removed over one hundred command-line options as part of the interface reorganization and implemented significant additional testing. NeoPG appears promising as an alternative OpenPGP implementation for both direct use and inclusion as a library.

Key distribution

The most difficult problem in encrypted communications is key distribution—establishing that the keys used to contact another person actually belong to that person. Historically, OpenPGP implementations have solved this problem using a model called the "web of trust" (WoT). In that model, users verify the keys of other individuals and then cryptographically sign those keys. Eventually, this forms a graph of keys verified by multiple users that can be used to transitively trust keys that cannot be verified in person. For example, if Alice needs to securely contact Charlie but cannot personally verify his key (for example, by meeting in person), a third user that Alice has personally verified may have verified Charlie, giving Alice some second-hand confidence that Charlie's key is correct.

While this works in theory, in practice there are many challenges. Verifying and becoming verified by enough people to become well-connected to the web of trust requires a significant investment of time and effort that discourages new users; those same new users often find the web of trust model, itself, and the GnuPG implementation details to be confusing and difficult to use.

One substitute for the web of trust which is increasingly adopted in the PGP ecosystem is "trust on first use" (TOFU). Implementations of this technique, of which the OpenSSH client is likely the best known, focus on detecting a man-in-the-middle attack based on the attacker having a different key pair than the legitimate destination of a message—once you have communicated with someone once, their key should never change. This is a powerful concept and is effective in preventing a man-in-the-middle attack once you have first communicated with someone. However, if you are contacting someone for the first time, you don't have any previous key to rely on and the communication is still subject to a man in the middle, which may require a stronger key validation method.

There have been many efforts to replace or augment the web of trust with a simpler and easier system that still reliably identifies a key's owner on the first use. These approaches are often based on authoritatively tying keys to other personal information like email addresses. For example, the PGP Corporation (now Symantec) operates a keyserver that verifies the email address associated with a submitted key and then signs the key. By trusting Symantec's verification key for this service, a GnuPG user can have some confidence that each signed key really belongs to the person with the indicated email address.

A more interesting approach to this problem comes from the commercial service Keybase, which produces an open-source tool to verify ownership of a key based on assertions published to web sites and social media services. For example, the keybase tool can automatically check a signed statement uploaded to GitHub's Gist pastebin service to prove that a PGP key belongs to the owner of the GitHub account. This has the major advantage that the actual verification process is decentralized: the Keybase tool validated these posted identity proofs independently without relying on or trusting the Keybase service.

Keybase is not a complete solution, as it suffers from the obvious problem that many users of powerful cryptographic software intentionally avoid using social networks. The concept of tying cryptographic keys to other types of online identity is a powerful one, though, and NeoPG aims to both integrate support for Keybase and implement a keyserver that provides email verification similar to that done by Symantec.

While the GnuPG project has gone through difficult times, an uptick in development effort on GnuPG itself, as well as development on competitors, is promising for the future of open-source public-key cryptography systems. There is still a long distance to cover, though, particularly in the space of user-friendly key distribution systems, which are currently dominated by centralized, commercial offerings.