The GnuPG 2.1 release

GNU Privacy Guard (GnuPG) is the best-known free-software implementation of the OpenPGP cryptography standard. For the past few years, the GnuPG project has actively maintained its existing stable branch, version 2.0.x, its "classic" branch (version 1.4), and continued working on a more modern replacement that implements several important improvements. In early November, the project made its first official release of this development code: GnuPG 2.1.0. There are quite a few interesting changes to be found in version 2.1, although the decision to switch over from the 2.0 series to 2.1 should, nevertheless, be carefully considered.

The new release is available as source code bundles directly from the GnuPG project. Despite several beta releases of version 2.1 over the years (the first was in 2010), the project still emphasizes that the 2.1 series has not yet been subjected to extensive real-world testing. Nevertheless, it is referring to 2.1.0 as the "modern" series, rather than as "unstable" or some other designation suggesting that it is not ready for deployment.

It is vital to note, however, that version 2.1 cannot be installed simultaneously with the 2.0 series. In addition to affecting those users who are interested in compiling the new release for themselves, this also means it is likely to be some time before binary 2.1 packages make their way into many Linux distributions. The "classic" 1.4 series, though, can be installed alongside either GnuPG 2.0 or 2.1

Interfaces and key storage

Several changes in 2.1 will be noticed immediately by GnuPG users because they introduce interface changes to the command set and differences in how secret material is stored. For example, previous GnuPG versions have all stored public-key pairs in two separate files. The secring.gpg file contained both the public and private keys for a user's key pairs, while the pubring.gpg file contained just the public half of those same pairs. That design decision meant that GnuPG had to work to ensure that the two files remained in sync, increasing code complexity.

The new design does away with the two-file setup, and keeps private keys inside a key-store directory (~/.gnupg/private-keys-v1.d). In addition, the code required to manage the secring.gpg file has been factored out of the gpg binary. Instead, secret key management is handled entirely by the gpg-agent daemon. The new design also enables some other long-requested features, such as the ability to import a subkey into an existing secret key. gpg-agent is also started on demand by the GnuPG tools, whereas in past releases, users needed to start it manually or by adding it to a session-startup script.

The storage of public keys has also changed in the new release. GnuPG 2.1 stores public keys in a "keybox" file that was originally developed for GnuPG's S/MIME tool, gpgsm. It is optimized for read efficiency; since the number of public keys a user has on file typically outnumbers the number of private keys (and often by a large margin), providing fast access to the public key store is important.

Several of the GnuPG command-line tools have also received a refresh. In particular, the key-generation interface is now faster, by virtue of only requiring users to enter a name and email address: the many other possible parameters for a key can be filled by default values (which is likely to reduce errors in addition to saving time). This quick-generation behavior is used when gpg2 --gen-key is invoked; the full interface as found in earlier releases can be triggered with gpg2 --full-gen-key.

Other conveniences for key-generation are found in the new release. First, there are now "quick" versions of the key-generation and key-signing commands, developed in order to save time when performing repetitive tasks. Running

    gpg2 --quick-gen-key 'John Doe <doe@example.net>'

or

    gpg2 --quick-sign-key '1234 5678 90AB CDEF 1234 5678' 

will prompt the user for a yes/no confirmation, but will otherwise perform the requested operations without further questions. Both commands, though, do perform basic sanity checks and will warn the user if (for example) asked to create a key for a name/email pair that already exists.

Second, key-revocation certificates are now created by default and saved in the directory ~/.gnupg/openpgp-revocs.d/. Each revocation certificate even includes brief instructions for usage at the top of the file. Since the preparation of revocation certificates before they are needed falls under the "good ideas that are easy to forget" umbrella, this is likely a change many users will appreciate.

Finally, the command-line key listing format has been changed to be more informative. For traditional encryption algorithms, the algorithm name has been reformatted for clarity (e.g., dsa2048 rather than 2048D). For elliptic curve cryptography (ECC), the name of the curve is displayed, rather than the algorithm.

Ellipses ....

ECC support, of course, is another major feature that debuts in GnuPG 2.1—for some users, it may even be the most significant change. According to the release notes, GnuPG 2.1 is the first "mainstream" implementation of public-key ECC in an OpenPGP tool, a fact that has an upside and a downside as well. The downside, naturally, is that ECC keys are not widely deployed. The upside is that GnuPG's support for ECC should make deploying such keys relatively easy.

Nevertheless, GnuPG 2.1 still hides the ECC key-generation option by default. Users must use the --gen-full-key option and add the --expert flag to see it. ECC support is an OpenPGP extension documented in RFC 6637.

At the moment, GnuPG supports seven different ECC curves: Curve25519, NIST P-256, NIST P-384, NIST P-521, Brainpool P-256, Brainpool P-384, and Brainpool P-512. The Curve25519 support, for now, is limited to digital signature and not encryption. It is not part of the OpenPGP standard (although IETF approval is expected by many to arrive someday), but it is still noteworthy. It is regarded by many in the community as safer than the NIST (US National Institute of Standards and Technology) and Brainpool curves, which are suspected of being vulnerable to US government codebreakers.

On the subject of bad cryptography, all support for PGP-2 keys has been removed in GnuPG 2.1. PGP-2 keys are no longer regarded as safe, in particular because the algorithms mandate the use of the MD5 hash function. GnuPG 2.1 will no longer import PGP-2 keys, and the project recommends that users keep a copy of GnuPG 1.4 on hand if they need to decrypt data that has been previously encrypted with a PGP-2 key.

Additional features

There are, of course, many other smaller feature additions and enhancements to be found in the new release. X.509 certificate creation has been improved in a number of ways, for example. Users can create self-signed certificates, create batches of certificates based on a parameter file, and can export certificates directly to PKCS#8 or PKCS#1 format. This last feature allows users to create certificates for immediate use with OpenSSL servers (requiring no conversion). The batch-generation mode is also a feature that is already found in OpenSSL.

Smartcard support has been updated, with support for several new card-reader devices and hardware token types. Most notable on this front are the ability to use USB sticks with a built-in smartcard exactly like other smartcard devices and full support for Gnuk tokens (a free-software cryptographic token based on the STM32F103 microcontroller).

Finally, there have been several changes to the way GnuPG interoperates with keyservers. In prior releases, GnuPG spawned temporary processes to connect to remote keyservers—which meant that the program could not maintain any persistent state about the keyserver. The new release merges in a formerly separate project called dirmngr that was previously limited to interacting with X.509 servers; it now manages keyserver connections as well.

One immediate benefit of using dirmngr to mediate keyserver access is that it can properly cope with keyserver pools. The issue is that Keyserver pools tend to be configured in round-robin arrangements, which works well enough until the specific keyserver GnuPG has connected to goes down or becomes unreachable. In prior releases, GnuPG would continue trying to access such an unreachable keyserver until the DNS entry for it expired. Dirmngr, in contrast, flags unreachable keyservers and sends another DNS lookup request to the pool—which should return a new, working host in considerably less time.

A security-critical program like GnuPG obviously warrants a high degree of scrutiny before a new release in adopted. To be sure, no one wants to migrate their company to a new PGP key format only to discover that there is a serious cryptographic flaw in the implementation of the new cipher. That said, there are certainly many new benefits to be found in GnuPG 2.1 over the 2.0 series. Hopefully, widespread vetting will come and more users can take advantage of ECC, updated smartcard support, and the many interface improvements offered.