gnupg/doc/whats-new-in-2.1.txt

                      ━━━━━━━━━━━━━━━━━━━━━━━━━━━
                       GNUPG - WHAT’S NEW IN 2.1


                              Werner Koch
                      ━━━━━━━━━━━━━━━━━━━━━━━━━━━


                               2017-08-28


Table of Contents
─────────────────

1 What’s new in GnuPG 2.1
.. 1.1 Removal of the secret keyring
.. 1.2 Removal of PGP-2 support
.. 1.3 Leaner key generation interface
.. 1.4 Support for ECC
.. 1.5 Quick generate and sign commands
.. 1.6 Improved Pinentry support
.. 1.7 Auto-start of the gpg-agent
.. 1.8 Duplicate long key id fixes
.. 1.9 Enhanced Dirmngr
.. 1.10 Better keyserver pool support
.. 1.11 Faster keyring format
.. 1.12 Auto-generated revocation certificates
.. 1.13 Improved card support
.. 1.14 New format for key listings
.. 1.15 Recipient key from file
.. 1.16 Using gpg as a filter
.. 1.17 Support for Putty
.. 1.18 Export of SSH public keys
.. 1.19 Improved X.509 certificate creation
.. 1.20 Scripts to create a Windows installer


A possibly revised version of this article can be found at:
https://gnupg.org/faq/whats-new-in-2.1.html


1 What’s new in GnuPG 2.1
═════════════════════════

  GnuPG version 2.1 (now known as 2.2) comes with a bag of new features
  which changes some things old-timers are used to.  This page explains
  the more important ones.  It expects that the reader is familiar with
  GnuPG version 2.0 and aware that GnuPG consists of /gpg/, /gpgsm/, and
  /gpg-agent/ as its main components.

  • The file /secring.gpg/ is not anymore used to store the secret keys.
    Merging of secret keys is now supported.

  • All support for /PGP-2 keys/ has been removed for security reasons.

  • The standard key generation interface is now much leaner.  This will
    help a new user to quickly generate a suitable key.

  • Support for /Elliptic Curve Cryptography/ (ECC) is now available.

  • Commands to create and sign keys from the command line without any
    extra prompts are now available.

  • The Pinentry may now show the new passphrase entry and the
    passphrase confirmation entry in one dialog.

  • There is no more need to manually start the gpg-agent.  It is now
    started by any part of GnuPG as needed.

  • Problems with importing keys with the same long key id have been
    addressed.

  • The /dirmngr/ is now part of GnuPG proper and also takes care of
    accessing keyserver.

  • Keyserver pools are now handled in a smarter way.

  • A new format for locally storing the public keys is now used.  This
    considerable speeds up operations on large keyrings.

  • /Revocation certificates/ are now created by default.

  • Card support has been updated, new readers and token types are
    supported.

  • The format of the key listing has been changed to better identify
    the properties of a key.

  • A file with the recipient’s key may now be used directly.

  • Gpg can be used to filter out parts of a key.

  • The gpg-agent may now be used on Windows as /pageant/ replacement
    for /putty/ in the same way it is used for years on Unix as
    /ssh-agent/ replacement.

  • Creation of X.509 certificates has been improved.  It is now also
    possible to export them directly in PKCS#8 and PEM format for use on
    TLS servers.

  • Export of /ssh/ keys has been integrated.

  • The scripts to create a Windows installer are now part of GnuPG.

  Now for the detailed description of these new features.  Note that the
  examples assume that /gpg/ is installed as /gpg/.  Your installation
  may have it installed under the name /gpg2/.


1.1 Removal of the secret keyring
─────────────────────────────────

  gpg used to keep the public key pairs in two files: `pubring.gpg' and
  `secring.gpg'.  The only difference is that secring stored in addition
  to the public part also the private part of the key pair.  The secret
  keyring thus contained only the keys for which a private key is
  available, that is the user’s key.  It required a lot of code to keep
  both versions of the key in sync and led to sometimes surprising
  inconsistencies.

  The design of GnuPG-2 demands that only the gpg-agent has control over
  the private parts of the keys and the actual encryption engine (gpg or
  gpgsm) does not know about the private key but care only about session
  keys and keys for symmetric encryption.  This has been implemented
  about 10 years ago for /gpgsm/ (the S/MIME part of GnuPG).  However,
  /gpg/ (the OpenPGP part) used the gpg-agent only as passphrase entry
  and cache device but handles the private key itself.

  With GnuPG 2.1 this changed and /gpg/ now also delegates all private
  key operations to the gpg-agent.  Thus there is no more code in the
  /gpg/ binary for handling private keys.  En passant this allows the
  long time requested “merging of secret keys” and several other
  advanced key management techniques.

  To ease the migration to the no-secring method, /gpg/ detects the
  presence of a `secring.gpg' and converts the keys on-the-fly to the
  the key store of /gpg-agent/ (this is the `private-keys-v1.d'
  directory below the GnuPG home directory (`~/.gnupg')).  This is done
  only once and an existing `secring.gpg' is then not anymore touched by
  /gpg/.  This allows co-existence of older GnuPG versions with GnuPG
  2.1.  However, any change to the private keys using the new /gpg/ will
  not show up when using pre-2.1 versions of GnuPG and vice versa.

  Note that the command `--export-secret-keys' still creates an OpenPGP
  compliant file with the secret keys.  This is achieved by asking
  /gpg-agent/ to convert a key and return it in the OpenPGP protected
  format.  The export operation requires that the passphrase for the key
  is entered so that /gpg-agent/ is able to change the protection from
  its internal format to the OpenPGP required format.


1.2 Removal of PGP-2 support
────────────────────────────

  Some algorithms and parts of the protocols as used by the 20 years old
  [PGP-2] software are meanwhile considered unsafe.  In particular the
  baked in use of the [MD5] hash algorithm limits the security of PGP-2
  keys to non-acceptable rate.  Technically those PGP-2 keys are called
  version 3 keys (v3) and are easily identified by a shorter fingerprint
  which is commonly presented as 16 separate double hex digits.

  With GnuPG 2.1 all support for those keys has gone.  If they are in an
  existing keyring they will eventually be removed.  If GnuPG encounters
  such a key on import it will not be imported due to the not anymore
  implemented v3 key format.  Removing the v3 key support also reduces
  complexity of the code and is thus better than to keep on handling
  them with a specific error message.

  There is one use case where PGP-2 keys may still be required: For
  existing encrypted data.  We suggest to keep a version of GnuPG 1.4
  around which still has support for these keys (it might be required to
  use the `--allow-weak-digest-algos' option).  A better solution is to
  re-encrypt the data using a modern key.


  [PGP-2] https://en.wikipedia.org/wiki/Pretty_Good_Privacy

  [MD5] https://en.wikipedia.org/wiki/MD5


1.3 Leaner key generation interface
───────────────────────────────────

  This is best shown with an example:

  ┌────
  │ $ gpg --gen-key
  │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
  │ This is free software: you are free to change and redistribute it.
  │ There is NO WARRANTY, to the extent permitted by law.
  │
  │ gpg: keybox '/home/foo/.gnupg/pubring.kbx' created
  │ Note: Use "gpg --full-gen-key" for a full featured key generation dialog.
  │
  │ GnuPG needs to construct a user ID to identify your key.
  │
  │ Real name: Glenn Greenwald
  │ Email address: glenn@example.org
  │ You selected this USER-ID:
  │     "Glenn Greenwald <glenn@example.org>"
  │
  │ Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
  │ [...]
  │ pub   rsa2048/68FD0088 2014-11-03
  │       Key fingerprint = 0290 5ABF 17C7 81FB C390  9B00 636A 1BBD 68FD 0088
  │ uid       [ultimate] Glenn Greenwald <glenn@example.org>
  │ sub   rsa2048/84439DCD 2014-11-03
  └────

  Thus only the name and the mail address are required.  For all other
  parameters the default values are used.  Many graphical frontends
  works in the same way.  Note that /gpg/ prints a hint for the old time
  gpg users on how to get the full option menu.


1.4 Support for ECC
───────────────────

  GnuPG now support Elliptic Curve keys for public key encryption.  This
  is defined in [RFC-6637].  Because there is no other mainstream
  OpenPGP implementation yet available which supports ECC, the use of
  such keys is still very limited.  Thus GnuPG 2.1 currently hides the
  options to create an ECC key.

  For those who want to experiment with ECC or already want to prepare a
  key for future use, the command `--full-gen-key' along with the option
  `--expert' is the enabler:

  ┌────
  │ $ gpg --expert --full-gen-key
  │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
  │ This is free software: you are free to change and redistribute it.
  │ There is NO WARRANTY, to the extent permitted by law.
  │
  │ Please select what kind of key you want:
  │    (1) RSA and RSA (default)
  │    (2) DSA and Elgamal
  │    (3) DSA (sign only)
  │    (4) RSA (sign only)
  │    (7) DSA (set your own capabilities)
  │    (8) RSA (set your own capabilities)
  │    (9) ECC and ECC
  │   (10) ECC (sign only)
  │   (11) ECC (set your own capabilities)
  │ Your selection? 9
  │ Please select which elliptic curve you want:
  │    (2) NIST P-256
  │    (3) NIST P-384
  │    (4) NIST P-521
  │    (5) Brainpool P-256
  │    (6) Brainpool P-384
  │    (7) Brainpool P-512
  │ Your selection? 2
  │ Please specify how long the key should be valid.
  │          0 = key does not expire
  │       <n>  = key expires in n days
  │       <n>w = key expires in n weeks
  │       <n>m = key expires in n months
  │       <n>y = key expires in n years
  │ Key is valid for? (0)
  │ Key does not expire at all
  │ Is this correct? (y/N) y
  │
  │ GnuPG needs to construct a user ID to identify your key.
  │
  │ Real name: Edward Snowden
  │ Email address: edward@example.org
  │ Comment:
  │ You selected this USER-ID:
  │     "Edward Snowden <edward@example.org>"
  │
  │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
  │ [...]
  │ pub   nistp256/382660E3 2014-11-03
  │       Key fingerprint = E630 27CF 3D68 22A7 6FF2  093E D179 9E72 3826 60E3
  │ uid       [ultimate] Edward Snowden <edward@example.org>
  │ sub   nistp256/48C9A997 2014-11-03 nistp256
  └────

  In this example we created a primary ECC key for signing and an subkey
  for encryption.  For both we use the NIST P-256 curve.  The key may
  now be used in the same way as any other key.  It is possible to add
  an RSA subkey or one can create an RSA or DSA main key and add an ECC
  subkey for signing or encryption.  Note that the list of offered
  curves depends on the installed Libgcrypt version.

  For many people the NIST and also the Brainpool curves have an
  doubtful origin and thus the plan for GnuPG is to use Bernstein’s
  [Curve 25519] as default.  GnuPG 2.1.0 already comes with support for
  signing keys using the [Ed25519] variant of this curve.  This has not
  yet been standardized by the IETF (i.e. there is no RFC) but we won’t
  wait any longer and go ahead using the proposed format for this
  signing algorithm.  The format for an encryption key has not yet been
  finalized and will be added to GnuPG in one of the next point
  releases.  Recall that an encryption subkey can be added to a key at
  any time.  If you want to create a signing key you may do it this way:

  ┌────
  │ $ gpg --expert --full-gen-key
  │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
  │ This is free software: you are free to change and redistribute it.
  │ There is NO WARRANTY, to the extent permitted by law.
  │
  │ Please select what kind of key you want:
  │    (1) RSA and RSA (default)
  │    (2) DSA and Elgamal
  │    (3) DSA (sign only)
  │    (4) RSA (sign only)
  │    (7) DSA (set your own capabilities)
  │    (8) RSA (set your own capabilities)
  │    (9) ECC and ECC
  │   (10) ECC (sign only)
  │   (11) ECC (set your own capabilities)
  │ Your selection? 10
  │ Please select which elliptic curve you want:
  │    (1) Curve 25519
  │    (2) NIST P-256
  │    (3) NIST P-384
  │    (4) NIST P-521
  │    (5) Brainpool P-256
  │    (6) Brainpool P-384
  │    (7) Brainpool P-512
  │ Your selection? 1
  │ gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard.
  │ Use this curve anyway? (y/N) y
  │ Please specify how long the key should be valid.
  │          0 = key does not expire
  │       <n>  = key expires in n days
  │       <n>w = key expires in n weeks
  │       <n>m = key expires in n months
  │       <n>y = key expires in n years
  │ Key is valid for? (0)
  │ Key does not expire at all
  │ Is this correct? (y/N) y
  │
  │ GnuPG needs to construct a user ID to identify your key.
  │
  │ Real name: Laura Poitras
  │ Email address: laura@example.org
  │ Comment:
  │ You selected this USER-ID:
  │     "Laura Poitras <laura@example.org>"
  │
  │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
  │ [...]
  │ pub   ed25519/5C1AFC2A 2014-11-03
  │       Key fingerprint = ED85 4D98 5D8F 502F C6C5  FFB2 AA81 319E 5C1A FC2A
  │ uid       [ultimate] Laura Poitras <laura@example.org>
  └────

  Support for ECC keys is available only on some keyservers but it is
  expected that this will be fixed over the next few months.


  [RFC-6637] https://rfc-editor.org/info/rfc6637

  [Curve 25519] http://cr.yp.to/ecdh/curve25519-20060209.pdf

  [Ed25519] http://dx.doi.org/10.1007/s13389-012-0027-1


1.5 Quick generate and sign commands
────────────────────────────────────

  Sometimes it is useful to use only command line options without any
  parameter file or interactive prompts for generating a key or to sign
  a key.  This can now be accomplished with a few new commands:

  ┌────
  │ $ gpg --batch --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
  │ gpg: key 911B90A9 marked as ultimately trusted
  └────

  If a key with that user id already exists, gpg bails out with an error
  message.  You can force creation using the option `--yes'.  If you
  want some more control, you may not use `--batch' and gpg will ask for
  confirmation and show the resulting key:

  ┌────
  │ $ gpg --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
  │ About to create a key for:
  │     "Daniel Ellsberg <ellsberg@example.org>"
  │
  │ Continue? (Y/n) y
  │ gpg: A key for "Daniel Ellsberg <ellsberg@example.org>" already exists
  │ Create anyway? (y/N) y
  │ gpg: creating anyway
  │ [...]
  │ pub   rsa2048/BD19AC1C 2014-11-04
  │       Key fingerprint = 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
  │ uid       [ultimate] Daniel Ellsberg <ellsberg@example.org>
  │ sub   rsa2048/72A4D018 2014-11-04
  └────

  Another common operation is to sign a key.  /gpg/ can do this directly
  from the command line by giving the fingerprint of the to-be-signed
  key:

  ┌────
  │ $ gpg --quick-sign-key  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
  │
  │ pub  rsa2048/BD19AC1C
  │      created: 2014-11-04  expires: never       usage: SC
  │      trust: ultimate      validity: ultimate
  │  Primary key fingerprint: 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
  │
  │      Daniel Ellsberg <ellsberg@example.org>
  └────

  In case the key has already been signed, the command prints a note and
  exits with success.  In case you want to check that it really worked,
  use `--check-sigs' as usual:

  ┌────
  │ $ gpg --check-sigs  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
  │ gpg: checking the trustdb
  │ gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
  │ gpg: depth: 0  valid:   6  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 6u
  │ pub   rsa2048/BD19AC1C 2014-11-04
  │ uid       [  full  ] Daniel Ellsberg <ellsberg@example.org>
  │ sig!3        BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
  │ sig!         68FD0088 2014-11-04  Glenn Greenwald <glenn@example.org>
  │ sub   rsa2048/72A4D018 2014-11-04
  │ sig!         BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
  └────


  The fingerprint may also be given without the spaces in which case
  there is no need for the quotes.  If you want to sign only certain
  user ids of a key, list those user id verbatim after the fingerprint.
  To create a non-exportable key signature, use the command
  `--quick-lsign-key' instead.

  Since version 2.1.4 it possible to directly add another user id to an
  existing key:

  ┌────
  │ $ gpg -k 8CFDE12197965A9A
  │ pub   ed25519/8CFDE12197965A9A 2014-08-19
  │ uid               [ unknown] EdDSA sample key 1
  │ $ gpg --quick-adduid 8CFDE12197965A9A 'Sample 2 <me@example.org>'
  │ $ gpg -k 8CFDE12197965A9A
  │ pub   ed25519/8CFDE12197965A9A 2014-08-19
  │ uid               [ unknown] Sample 2 <me@example.org>
  │ uid               [ unknown] EdDSA sample key 1
  └────

  Since version 2.1.13 another subkey can directly be added to an
  existing key:

  ┌────
  │ $ gpg --quick-addkey 15CB723E2000A1A82505F3B7CC00B501BD19AC1C - - 2016-12-31
  │ $ gpg -k 15CB723E2000A1A82505F3B7CC00B501BD19AC1C
  │ pub   rsa2048 2014-11-04 [SC]
  │       15CB723E2000A1A82505F3B7CC00B501BD19AC1C
  │ uid           [ unknown] Daniel Ellsberg <ellsberg@example.org>
  │ sub   rsa2048 2014-11-04 [E]
  │ sub   rsa2048 2016-06-06 [E] [expires: 2016-12-31]
  └────

  Here we created another encryption subkey with an expiration date.
  The key listing also shows the default key listing format introduced
  with 2.1.13.  There are a lot of other options to the `--quick-addkey'
  command which are described in the manual.

  Since version 2.1.14 it possible to revoke a user id on an existing
  key:

  ┌────
  │ $ gpg -k 8CFDE12197965A9A
  │ pub   ed25519/8CFDE12197965A9A 2014-08-19
  │ uid               [ unknown] Sample 2 <me@example.org>
  │ uid               [ unknown] EdDSA sample key 1
  │ $ gpg --quick-revuid 8CFDE12197965A9A 'EdDSA sample key 1'
  │ $ gpg -k 8CFDE12197965A9A
  │ pub   ed25519/8CFDE12197965A9A 2014-08-19
  │ uid               [ unknown] Sample 2 <me@example.org>
  └────

  Since version 2.1.17 the expiration date of the primary key can be
  changed directly:

  ┌────
  │ $ gpg --quick-set-expire 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7 2017-12-31
  │ $ gpg -K 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
  │ sec   rsa2048 2016-06-22 [SC] [expires: 2017-12-31]
  │       5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
  │ uid           [ultimate] steve.biko@example.net
  │ ssb   rsa2048 2016-06-22 [E]
  │
  │ $ gpg --quick-set-expire 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7 none
  │ $ gpg -K 5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
  │ sec   rsa2048 2016-06-22 [SC]
  │       5B83120DB1E3A65AE5A8DCF6AA43F1DCC7FED1B7
  │ uid           [ultimate] steve.biko@example.net
  │ ssb   rsa2048 2016-06-22 [E]
  └────


1.6 Improved Pinentry support
─────────────────────────────

  When using a recent Pinentry module (0.90, GTK+ variant), the
  gpg-agent will not anymore show two separate Pinentry dialogs to enter
  a new passphrase and later to confirm the new passphrase.  Instead the
  first dialog also has the confirm/repeat entry and internally checks
  whether they match.

  With any Pinentry version the several separate dialogs to inform and
  ask for confirmation about questionable properties of a new passphrase
  (e.g. length, only alpha letters) have been combined into one dialog
  to show all non-asserted constraints at once.

  The GTK+ Pinentry does now allow pasting of values into the entries.
  Copying them from the entries is still inhibited on purpose.
  Depending on the system, the option `no-grab' may be required for in
  the `gpg-agent.conf' file to actually make use of the paste feature.


1.7 Auto-start of the gpg-agent
───────────────────────────────

  The /gpg-agent/ is the central part of the GnuPG system.  It takes
  care of all private (secret) keys and if required diverts operations
  to a smartcard or other token.  It also provides support for the
  Secure Shell by implementing the ssh-agent protocol.

  The classic way to run /gpg-agent/ on Unix systems is by launching it
  at login time and use an environment variable (`GPG_AGENT_INFO') to
  tell the other GnuPG modules how to connect to the agent.  However,
  correctly managing the start up and this environment variable is
  cumbersome so that an easier method is required.  Since GnuPG 2.0.16
  the `--use-standard-socket' option already allowed to start the agent
  on the fly; however the environment variable was still required.

  With GnuPG 2.1 the need of `GPG_AGENT_INFO' has been completely
  removed and the variable is ignored.  Instead a fixed Unix domain
  socket named `S.gpg-agent' in the GnuPG home directory (by default
  `~/.gnupg') is used.  The agent is also started on demand by all tools
  requiring services from the agent.

  If the option `--enable-ssh-support' is used the auto-start mechanism
  does not work because /ssh/ does not know about this mechanism.
  Instead it is required that the environment variable `SSH_AUTH_SOCK'
  is set to the `S.gpg-agent.ssh' socket in the GnuPG home directory.
  Further /gpg-agent/ must be started: Either by using a GnuPG command
  which implicitly starts /gpg-agent/ or by using `gpgconf --launch
  gpg-agent' to explicitly start it if not yet done.


1.8 Duplicate long key id fixes
───────────────────────────────

  A deficit of the OpenPGP protocol is that signatures carry only a
  limited indication on which public key has been used to create a
  signature.  Thus a verification engine may only use this “long key id”
  to look up the key in its own store or from a public keyserver.
  Unfortunately it has now become possible to create a key with a long
  key id matching the key id of another key.  Importing a key with a
  long key id already used by another key in gpg’s local key store was
  not possible due to checks done on import.  Now, if the “wrong” key
  has been imported first /gpg/ would not allow later import of the
  second “correct” key.  This problem has been fixed in 2.1 by allowing
  the import and by doing trial verification against all matching keys.


1.9 Enhanced Dirmngr
────────────────────

  Before version 2.1, /gpg/ used so-called keyserver helpers to access
  the OpenPGP keyservers.  A problem with that is that they are short
  living processes which are not able to keep a state.  With 2.1, the
  formerly separate package Dirmngr (which was separate due to copyright
  assignment reasons) has been integrated into GnuPG.

  In the past /dirmngr/ was only used by /gpgsm/ for X.509 (S/MIME) CRL
  and OCSP handling.  Being a proper part of GnuPG /dirmngr/ does now
  also care about accessing OpenPGP keyservers.  This make its easier to
  debug problems with the keyservers and to exchange additional
  information about the keyserver between /gpg/ and /dirmngr/.  It will
  eventually also be possible to run background tasks to refresh keys.

  Although the ability to start /dirmngr/ as a system service is still
  available, this is not anymore recommended and instead /dirmngr/ is
  now by default started on-demand, very similar to /gpg-agent/.


1.10 Better keyserver pool support
──────────────────────────────────

  For load balancing reasons, keyservers are organized in pools to
  enable instant round-robin DNS assignment of random keyservers.  A
  problem with that approach is that the DNS resolver is not aware of
  the state of the keyserver.  If a keyserver has gone down or a routing
  problems occurs, /gpg/ and its keyserver helpers were not aware of it
  and would try over and over to use the same, dead, keyserver up until
  the DNS information expires and a the DNS resolver assigned a new
  server from the pool.

  The new /dirmngr/ in GnuPG does not use the implicit round-robin of
  the DNS resolver but uses its own DNS lookup and keeps an internal
  table of all hosts from the pool along with the encountered aliveness
  state.  Thus after a failure (timeout) of a request, /dirmngr/ flags a
  host as dead and randomly selects another one from the pool.  After a
  few hours the flag is removed so that the host will be tried again.
  It is also possible to mark a specific host from a pool explicitly as
  dead so that it won’t be used in the future.  To interact with the
  /dirmngr/ the `gpg-connect-agent' tool is used:

  ┌────
  │ $ gpg-connect-agent --dirmngr 'help keyserver' /bye
  │ $ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
  └────

  The first command prints a help screen for the keyserver command and
  the second command prints the current host table.


1.11 Faster keyring format
──────────────────────────

  The format GnuPG has always used for the public keyring is actually a
  slightly extended version of the on-the-wire format for OpenPGP key
  exchange.  This format is quite inflexible to work with when random
  access to keys in the keyring is required.  In fact /gpg/ always
  parsed all keys in the keyring until it encountered the desired one.
  With a large keyring (more than a few thousand keys) this could be
  quite slow.

  From its very beginning /gpgsm/ has used a different format to store
  public keys (certificates) which we call a /keybox/. That file format
  carries meta information about the stored keys and thus allows
  searching without actually parsing the key and computing fingerprints
  and such.  The /keybox/ format has been designed to be protocol
  independent and with 2.1 support for OpenPGP keys has been added.
  Random access to the keys is now really fast and keyrings with 30000
  keys and more are now easily possible.  That change also enables us to
  easily introduce other storage methods

  If no `pubring.gpg' is found, /gpg/ defaults to the new /keybox/
  format and creates a `pubring.kbx' keybox file.  If such a keybox file
  already exists, for example due to the use of /gpgsm/, it will also be
  used for OpenPGP keys.  However, if a `pubring.gpg' is found and no
  keybox file with OpenPGP keys exists, the old `pubring.gpg' will be
  used.  Take care: GnuPG versions before 2.1 will always use the
  `pubring.gpg' file and not know anything about keys stored in the
  keybox file.

  To convert an existing `pubring.gpg' file to the keybox format, you
  first backup the ownertrust values, then rename the file to (for
  example) `publickeys', so it won’t be recognized by any GnuPG version,
  then run import, and finally restore the ownertrust values:

  ┌────
  │ $ cd ~/.gnupg
  │ $ gpg --export-ownertrust >otrust.lst
  │ $ mv pubring.gpg publickeys
  │ $ gpg --import-options import-local-sigs --import publickeys
  │ $ gpg --import-ownertrust otrust.lst
  └────

  You may then rename the `publickeys' file back so that it can be used
  by older GnuPG versions.  Remember that in this case you have two
  independent copies of the public keys.  The ownertrust values are kept
  by all gpg versions in the file `trustdb.gpg' but the above
  precautions need to be taken to keep them over an import.


1.12 Auto-generated revocation certificates
───────────────────────────────────────────

  This version creates an ASCII armored revocation certificate for each
  generated keypair and stores that certificate in a file named after
  the fingerprint of the key in the `openpgp-revocs.d' directory below
  the GnuPG home directory.  Brief instructions on how to use this
  revocation certificate are put at the top of the file.


1.13 Improved card support
──────────────────────────

  The /scdaemon/, which is responsible for accessing smardcards and
  other tokens, has received many updates.  In particular pluggable USB
  readers with a fixed card now work smoothless and similar to standard
  readers.  The latest features of the [gnuk] token are supported.  Code
  for the SmartCard-HSM has been added.  More card readers with a PIN
  pad are supported.  The internal CCID driver does now also work with
  certain non-auto-configuration equipped readers.

  Since version 2.1.19 multiple card readers are support and the format
  of the Pinentry prompts has been changed to show more information on
  the requested card.


  [gnuk] http://www.fsij.org/doc-gnuk/


1.14 New format for key listings
────────────────────────────────

  Due to the introduction of ECC keys the old format to list keys was
  not anymore suitable.  In particular, the length of an ECC key is
  defined but its expressiveness is limited without the other parameters
  of the curve.  The common way to describe an ECC key is by using the
  assigned name of its curve.  To allow for a common description we now
  either use the algorithm name with appended key length or use the name
  of the curve:

  ┌────
  │ pub   2048D/1E42B367 2007-12-31 [expires: 2018-12-31]
  │
  │ pub   dsa2048 2007-12-31 [SC] [expires: 2018-12-31]
  │       80615870F5BAD690333686D0F2AD85AC1E42B367
  │
  │ pub   ed25519 2014-10-18 [SC]
  │       0B7F0C1D690BC440D5AFF9B56902F00A0AA914C9
  └────

  The first two "pub"-items show the same key in the old format and in
  the new format.  The third "pub"-item shows an example of an ECC key
  using an ed25519 curve.  Note that since version 2.1.13 the key id is
  not anymore shown.  Instead the full fingerprint is shown in a compact
  format; by using the option `--with-fingerprint' the non-compact
  format is used.  The `--keyid-format' option can be used to switch
  back to the discouraged format which prints only the key id.

  As a further change the validity of a key is now shown by default;
  that is `show-uid-validity' is implicitly used for the
  `--list-options'.

  The annotated key listing produced by the `--with-colons' options did
  not change.  However a couple of new fields have been added, for
  example if the new option `--with-secret' is used the “S/N of a token
  field” indicates the presence of a secret key even in a public key
  listing.  This option is supported by recent [GPGME] versions and
  makes writing of key manager software easier.


  [GPGME] https://gnupg.org/software/gpgme/


1.15 Recipient key from file
────────────────────────────

  Since version 2.1.14 it is possible to specify the recipient’s key by
  providing a file with that key.  This done with the new options
  `--recipient-file' (or short `-f') and `--hidden-recipient-file' (or
  short `-F').  The file must containing exactly one key in binary or
  armored format.  All keys specified with those options are always
  considered fully valid.  These option may be mixed with the regular
  options to specify a key.  Along with the new convenience option
  `--no-keyring' it is now possible to encrypt data without maintaining
  a local keyring.


1.16 Using gpg as a filter
──────────────────────────

  Since version 2.1.14 the export and import options have been enhanced
  to allow the use of /gpg/ to modify a key without first storing it in
  the keyring.  For example:

  ┌────
  │ $ gpg --import-options import-minimal,import-export \
  │       --output smallkey.gpg --import key.gpg
  └────

  copies the keys in `keys.gpg' to `smallkey.gpg' while also removing
  all key signatures except for the latest self-signatures.  This can
  even be further restricted to copy only a specific user ID to the
  output file:

  ┌────
  │ $ gpg --import-options import-minimal,import-export \
  │       --import-filter keepuid='mbox = foo@example.org' \
  │       --output smallkey.gpg --import key.gpg
  └────

  Here the new `--import-filter' option is used to remove all user IDs
  except for those which have the mail address “foo@example.org”.  The
  same is also possible while exporting a key:

  ┌────
  │ $ gpg --export-filter keepuid='mbox = me@example.org' \
  │       --armor --export 8CFDE12197965A9A >smallkey.asc
  └────


1.17 Support for Putty
──────────────────────

  On Windows the new option `--enable-putty-support' allows gpg-agent to
  act as a replacement for [Putty]’s authentication agent /Pageant/.  It
  is the Windows counterpart for the `--enable-ssh-support' option as
  used on Unix.


  [Putty] http://www.chiark.greenend.org.uk/~sgtatham/putty/


1.18 Export of SSH public keys
──────────────────────────────

  The new command `--export-ssh-key' makes it easy to export an /ssh/
  public key in the format used for ssh’s `authorized_keys' file.  By
  default the command exports the newest subkey with an authorization
  usage flags.  A special syntax can be used to export other subkeys.
  This command is available since 2.1.11 and replaces the former debug
  utility /gpgkey2ssh/.


1.19 Improved X.509 certificate creation
────────────────────────────────────────

  In addition to an improved certificate signing request menu, it is now
  possible to create a self-signed certificate using the interactive
  menu of /gpgsm/.

  In batch mode the certificate creation dialog can now be controlled by
  a parameter file with several new keywords.  Such a parameter file
  allows the creation of arbitrary X.509 certificates similar to what
  can be done with /openssl/.  It may thus be used as the base for a CA
  software.  For details see the “CSR and certificate creation” section
  in the manual.

  The new commands `--export-secret-key-p8' and –export-secret-key-raw=
  may be used to export a secret key directly in PKCS#8 or PKCS#1
  format.  Thus X.509 certificates for TLS use may be managed by /gpgsm/
  and directly exported in a format suitable for OpenSSL based servers.


1.20 Scripts to create a Windows installer
──────────────────────────────────────────

  GnuPG now comes with the /speedo/ build system which may be used to
  quickly download and build GnuPG and all its direct dependencies on a
  decent Unix system.  See the README file for more instructions.

  The very same script may also be used to build a complete NSIS based
  installer for Windows using the mingw-w64 cross-compiler toolchain.
  That installer will feature GnuPG proper, GPA as graphical frontend,
  and GpgEX as a Windows Explorer extension.  GnuPG needs to be unpacked
  and from the top source directory you run this command

  ┌────
  │ make -f build-aux/speedo.mk w32-installer
  └────

  This command downloads all direct dependencies, checks the signatures
  using the GnuPG version from the build system (all Linux distros
  feature a suitable GnuPG tool), builds everything from source, and
  uses NSIS to create the installer.  Although this sounds easy, some
  experience in setting up a development machine is still required.
  Some versions of the toolchain exhibit bugs and thus your mileage may
  vary.  See the [Wiki] for more info.

  Support for keyserver access over TLS is currently not available but
  will be added with one of the next point releases.



  # Copyright 2014--2017 The GnuPG Project.
  # This work is licensed under the Creative Commons
  # Attribution-ShareAlike 4.0 International License.  To view a copy of
  # this license, visit http://creativecommons.org/licenses/by-sa/4.0/
  # or send a letter to Creative Commons, PO Box 1866, Mountain View, CA
  # 94042, USA.
  #
  # The canonical source for this article can be found in the gnupg-doc
  # git repository as web/faq/whats-new-in-2.1.org.


  [Wiki] https://wiki.gnupg.org/Build2.1_Windows