doc/whats-new-in-2.1.txt

   1                       ━━━━━━━━━━━━━━━━━━━━━━━━━━━
   2                        GNUPG - WHAT’S NEW IN 2.1
   3
   4
   5                               Werner Koch
   6                       ━━━━━━━━━━━━━━━━━━━━━━━━━━━
   7
   8
   9                                2016-01-14
  10
  11
  12 Table of Contents
  13 ─────────────────
  14
  15 1 What’s new in GnuPG 2.1
  16 .. 1.1 Removal of the secret keyring
  17 .. 1.2 Removal of PGP-2 support
  18 .. 1.3 Leaner key generation interface
  19 .. 1.4 Support for ECC
  20 .. 1.5 Quick generate and sign commands
  21 .. 1.6 Improved Pinentry support
  22 .. 1.7 Auto-start of the gpg-agent
  23 .. 1.8 Duplicate long key id fixes
  24 .. 1.9 Enhanced Dirmngr
  25 .. 1.10 Better keyserver pool support
  26 .. 1.11 Faster keyring format
  27 .. 1.12 Auto-generated revocation certificates
  28 .. 1.13 Improved card support
  29 .. 1.14 New format for key listings
  30 .. 1.15 Support for Putty
  31 .. 1.16 Export of SSH public keys
  32 .. 1.17 Improved X.509 certificate creation
  33 .. 1.18 Scripts to create a Windows installer
  34
  35
  36 A possibly revised version of this article can be found at:
  37 https://gnupg.org/faq/whats-new-in-2.1.html
  38
  39
  40 1 What’s new in GnuPG 2.1
  41 ═════════════════════════
  42
  43   GnuPG version 2.1 comes with a bag of new features which changes some
  44   things old-timers are used to.  This page explains the more important
  45   ones.  It expects that the reader is familiar with GnuPG version 2.0
  46   and aware that GnuPG consists of /gpg/, /gpgsm/, and /gpg-agent/ as
  47   its main components.
  48
  49   • The file /secring.gpg/ is not anymore used to store the secret keys.
  50     Merging of secret keys is now supported.
  51
  52   • All support for /PGP-2 keys/ has been removed for security reasons.
  53
  54   • The standard key generation interface is now much leaner.  This will
  55     help a new user to quickly generate a suitable key.
  56
  57   • Support for /Elliptic Curve Cryptography/ (ECC) is now available.
  58
  59   • Commands to create and sign keys from the command line without any
  60     extra prompts are now available.
  61
  62   • The Pinentry may now show the new passphrase entry and the
  63     passphrase confirmation entry in one dialog.
  64
  65   • There is no more need to manually start the gpg-agent.  It is now
  66     started by any part of GnuPG as needed.
  67
  68   • Problems with importing keys with the same long key id have been
  69     addressed.
  70
  71   • The /dirmngr/ is now part of GnuPG proper and also takes care of
  72     accessing keyserver.
  73
  74   • Keyserver pools are now handled in a smarter way.
  75
  76   • A new format for locally storing the public keys is now used.  This
  77     considerable speeds up operations on large keyrings.
  78
  79   • /Revocation certificates/ are now created by default.
  80
  81   • Card support has been updated, new readers and token types are
  82     supported.
  83
  84   • The format of the key listing has been changed to better identify
  85     the properties of a key.
  86
  87   • The gpg-agent may now be used on Windows as /pageant/ replacement
  88     for /putty/ in the same way it is used for years on Unix as
  89     /ssh-agent/ replacement.
  90
  91   • Creation of X.509 certificates has been improved.  It is now also
  92     possible to export them directly in PKCS#8 and PEM format for use on
  93     TLS servers.
  94
  95   • Export of /ssh/ keys has been integrated.
  96
  97   • The scripts to create a Windows installer are now part of GnuPG.
  98
  99   Now for the detailed description of these new features:
 100
 101
 102 1.1 Removal of the secret keyring
 103 ─────────────────────────────────
 104
 105   gpg used to keep the public key pairs in two files: `pubring.gpg' and
 106   `secring.gpg'.  The only difference is that secring stored in addition
 107   to the public part also the private part of the key pair.  The secret
 108   keyring thus contained only the keys for which a private key is
 109   available, that is the user’s key.  It required a lot of code to keep
 110   both versions of the key in sync and led to sometimes surprising
 111   inconsistencies.
 112
 113   The design of GnuPG-2 demands that only the gpg-agent has control over
 114   the private parts of the keys and the actual encryption engine (gpg or
 115   gpgsm) does not know about the private key but care only about session
 116   keys and keys for symmetric encryption.  This has been implemented
 117   about 10 years ago for /gpgsm/ (the S/MIME part of GnuPG).  However,
 118   /gpg/ (the OpenPGP part) used the gpg-agent only as passphrase entry
 119   and cache device but handles the private key itself.
 120
 121   With GnuPG 2.1 this changed and /gpg/ now also delegates all private
 122   key operations to the gpg-agent.  Thus there is no more code in the
 123   /gpg/ binary for handling private keys.  En passant this allows the
 124   long time requested “merging of secret keys” and several other
 125   advanced key management techniques.
 126
 127   To ease the migration to the no-secring method, /gpg/ detects the
 128   presence of a `secring.gpg' and converts the keys on-the-fly to the
 129   the key store of /gpg-agent/ (this is the `private-keys-v1.d'
 130   directory below the GnuPG home directory (`~/.gnupg')).  This is done
 131   only once and an existing `secring.gpg' is then not anymore touched by
 132   /gpg/.  This allows co-existence of older GnuPG versions with GnuPG
 133   2.1.  However, any change to the private keys using the new /gpg/ will
 134   not show up when using pre-2.1 versions of GnuPG and vice versa.
 135
 136   Note that the command `--export-secret-keys' still creates an OpenPGP
 137   compliant file with the secret keys.  This is achieved by asking
 138   /gpg-agent/ to convert a key and return it in the OpenPGP protected
 139   format.  The export operation requires that the passphrase for the key
 140   is entered so that /gpg-agent/ is able to change the protection from
 141   its internal format to the OpenPGP required format.
 142
 143
 144 1.2 Removal of PGP-2 support
 145 ────────────────────────────
 146
 147   Some algorithms and parts of the protocols as used by the 20 years old
 148   [PGP-2] software are meanwhile considered unsafe.  In particular the
 149   baked in use of the [MD5] hash algorithm limits the security of PGP-2
 150   keys to non-acceptable rate.  Technically those PGP-2 keys are called
 151   version 3 keys (v3) and are easily identified by a shorter fingerprint
 152   which is commonly presented as 16 separate double hex digits.
 153
 154   With GnuPG 2.1 all support for those keys has gone.  If they are in an
 155   existing keyring they will eventually be removed.  If GnuPG encounters
 156   such a key on import it will not be imported due to the not anymore
 157   implemented v3 key format.  Removing the v3 key support also reduces
 158   complexity of the code and is thus better than to keep on handling
 159   them with a specific error message.
 160
 161   There is one use case where PGP-2 keys may still be required: For
 162   existing encrypted data.  We suggest to keep a version of GnuPG 1.4
 163   around which still has support for these keys (it might be required to
 164   use the `--allow-weak-digest-algos' option).  A better solution is to
 165   re-encrypt the data using a modern key.
 166
 167
 168   [PGP-2] https://en.wikipedia.org/wiki/Pretty_Good_Privacy
 169
 170   [MD5] https://en.wikipedia.org/wiki/MD5
 171
 172
 173 1.3 Leaner key generation interface
 174 ───────────────────────────────────
 175
 176   This is best shown with an example:
 177
 178   ┌────
 179   │ $ gpg2 --gen-key
 180   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
 181   │ This is free software: you are free to change and redistribute it.
 182   │ There is NO WARRANTY, to the extent permitted by law.
 183   │
 184   │ gpg: keybox '/home/foo/.gnupg/pubring.kbx' created
 185   │ Note: Use "gpg --full-gen-key" for a full featured key generation dialog.
 186   │
 187   │ GnuPG needs to construct a user ID to identify your key.
 188   │
 189   │ Real name: Glenn Greenwald
 190   │ Email address: glenn@example.org
 191   │ You selected this USER-ID:
 192   │     "Glenn Greenwald <glenn@example.org>"
 193   │
 194   │ Change (N)ame, (E)mail, or (O)kay/(Q)uit? o
 195   │ [...]
 196   │ pub   rsa2048/68FD0088 2014-11-03
 197   │       Key fingerprint = 0290 5ABF 17C7 81FB C390  9B00 636A 1BBD 68FD 0088
 198   │ uid       [ultimate] Glenn Greenwald <glenn@example.org>
 199   │ sub   rsa2048/84439DCD 2014-11-03
 200   └────
 201
 202   Thus only the name and the mail address are required.  For all other
 203   parameters the default values are used.  Many graphical frontends
 204   works in the same way.  Note that /gpg/ prints a hint for the old time
 205   gpg users on how to get the full option menu.
 206
 207
 208 1.4 Support for ECC
 209 ───────────────────
 210
 211   GnuPG now support Elliptic Curve keys for public key encryption.  This
 212   is defined in [RFC-6637].  Because there is no other mainstream
 213   OpenPGP implementation yet available which supports ECC, the use of
 214   such keys is still very limited.  Thus GnuPG 2.1 currently hides the
 215   options to create an ECC key.
 216
 217   For those who want to experiment with ECC or already want to prepare a
 218   key for future use, the command `--full-gen-key' along with the option
 219   `--expert' is the enabler:
 220
 221   ┌────
 222   │ $ gpg2 --expert --full-gen-key
 223   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
 224   │ This is free software: you are free to change and redistribute it.
 225   │ There is NO WARRANTY, to the extent permitted by law.
 226   │
 227   │ Please select what kind of key you want:
 228   │    (1) RSA and RSA (default)
 229   │    (2) DSA and Elgamal
 230   │    (3) DSA (sign only)
 231   │    (4) RSA (sign only)
 232   │    (7) DSA (set your own capabilities)
 233   │    (8) RSA (set your own capabilities)
 234   │    (9) ECC and ECC
 235   │   (10) ECC (sign only)
 236   │   (11) ECC (set your own capabilities)
 237   │ Your selection? 9
 238   │ Please select which elliptic curve you want:
 239   │    (2) NIST P-256
 240   │    (3) NIST P-384
 241   │    (4) NIST P-521
 242   │    (5) Brainpool P-256
 243   │    (6) Brainpool P-384
 244   │    (7) Brainpool P-512
 245   │ Your selection? 2
 246   │ Please specify how long the key should be valid.
 247   │          0 = key does not expire
 248   │       <n>  = key expires in n days
 249   │       <n>w = key expires in n weeks
 250   │       <n>m = key expires in n months
 251   │       <n>y = key expires in n years
 252   │ Key is valid for? (0)
 253   │ Key does not expire at all
 254   │ Is this correct? (y/N) y
 255   │
 256   │ GnuPG needs to construct a user ID to identify your key.
 257   │
 258   │ Real name: Edward Snowden
 259   │ Email address: edward@example.org
 260   │ Comment:
 261   │ You selected this USER-ID:
 262   │     "Edward Snowden <edward@example.org>"
 263   │
 264   │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
 265   │ [...]
 266   │ pub   nistp256/382660E3 2014-11-03
 267   │       Key fingerprint = E630 27CF 3D68 22A7 6FF2  093E D179 9E72 3826 60E3
 268   │ uid       [ultimate] Edward Snowden <edward@example.org>
 269   │ sub   nistp256/48C9A997 2014-11-03 nistp256
 270   └────
 271
 272   In this example we created a primary ECC key for signing and an subkey
 273   for encryption.  For both we use the NIST P-256 curve.  The key may
 274   now be used in the same way as any other key.  It is possible to add
 275   an RSA subkey or one can create an RSA or DSA main key and add an ECC
 276   subkey for signing or encryption.  Note that the list of offered
 277   curves depends on the installed Libgcrypt version.
 278
 279   For many people the NIST and also the Brainpool curves have an
 280   doubtful origin and thus the plan for GnuPG is to use Bernstein’s
 281   [Curve 25519] as default.  GnuPG 2.1.0 already comes with support for
 282   signing keys using the [Ed25519] variant of this curve.  This has not
 283   yet been standardized by the IETF (i.e. there is no RFC) but we won’t
 284   wait any longer and go ahead using the proposed format for this
 285   signing algorithm.  The format for an encryption key has not yet been
 286   finalized and will be added to GnuPG in one of the next point
 287   releases.  Recall that an encryption subkey can be added to a key at
 288   any time.  If you want to create a signing key you may do it this way:
 289
 290   ┌────
 291   │ $ gpg2 --expert --full-gen-key
 292   │ gpg (GnuPG) 2.1.0; Copyright (C) 2014 Free Software Foundation, Inc.
 293   │ This is free software: you are free to change and redistribute it.
 294   │ There is NO WARRANTY, to the extent permitted by law.
 295   │
 296   │ Please select what kind of key you want:
 297   │    (1) RSA and RSA (default)
 298   │    (2) DSA and Elgamal
 299   │    (3) DSA (sign only)
 300   │    (4) RSA (sign only)
 301   │    (7) DSA (set your own capabilities)
 302   │    (8) RSA (set your own capabilities)
 303   │    (9) ECC and ECC
 304   │   (10) ECC (sign only)
 305   │   (11) ECC (set your own capabilities)
 306   │ Your selection? 10
 307   │ Please select which elliptic curve you want:
 308   │    (1) Curve 25519
 309   │    (2) NIST P-256
 310   │    (3) NIST P-384
 311   │    (4) NIST P-521
 312   │    (5) Brainpool P-256
 313   │    (6) Brainpool P-384
 314   │    (7) Brainpool P-512
 315   │ Your selection? 1
 316   │ gpg: WARNING: Curve25519 is not yet part of the OpenPGP standard.
 317   │ Use this curve anyway? (y/N) y
 318   │ Please specify how long the key should be valid.
 319   │          0 = key does not expire
 320   │       <n>  = key expires in n days
 321   │       <n>w = key expires in n weeks
 322   │       <n>m = key expires in n months
 323   │       <n>y = key expires in n years
 324   │ Key is valid for? (0)
 325   │ Key does not expire at all
 326   │ Is this correct? (y/N) y
 327   │
 328   │ GnuPG needs to construct a user ID to identify your key.
 329   │
 330   │ Real name: Laura Poitras
 331   │ Email address: laura@example.org
 332   │ Comment:
 333   │ You selected this USER-ID:
 334   │     "Laura Poitras <laura@example.org>"
 335   │
 336   │ Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? o
 337   │ [...]
 338   │ pub   ed25519/5C1AFC2A 2014-11-03
 339   │       Key fingerprint = ED85 4D98 5D8F 502F C6C5  FFB2 AA81 319E 5C1A FC2A
 340   │ uid       [ultimate] Laura Poitras <laura@example.org>
 341   └────
 342
 343   Support for ECC keys is available only on some keyservers but it is
 344   expected that this will be fixed over the next few months.
 345
 346
 347   [RFC-6637] https://rfc-editor.org/info/rfc6637
 348
 349   [Curve 25519] http://cr.yp.to/ecdh/curve25519-20060209.pdf
 350
 351   [Ed25519] http://dx.doi.org/10.1007/s13389-012-0027-1
 352
 353
 354 1.5 Quick generate and sign commands
 355 ────────────────────────────────────
 356
 357   Sometimes it is useful to use only command line options without any
 358   parameter file or interactive prompts for generating a key or to sign
 359   a key.  This can now be accomplished with a few new commands:
 360
 361   ┌────
 362   │ $ gpg2 --batch --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
 363   │ gpg: key 911B90A9 marked as ultimately trusted
 364   └────
 365
 366   If a key with that user id already exists, gpg bails out with an error
 367   message.  You can force creation using the option `--yes'.  If you
 368   want some more control, you may not use `--batch' and gpg will ask for
 369   confirmation and show the resulting key:
 370
 371   ┌────
 372   │ $ gpg2 --quick-gen-key 'Daniel Ellsberg <ellsberg@example.org>'
 373   │ About to create a key for:
 374   │     "Daniel Ellsberg <ellsberg@example.org>"
 375   │
 376   │ Continue? (Y/n) y
 377   │ gpg: A key for "Daniel Ellsberg <ellsberg@example.org>" already exists
 378   │ Create anyway? (y/N) y
 379   │ gpg: creating anyway
 380   │ [...]
 381   │ pub   rsa2048/BD19AC1C 2014-11-04
 382   │       Key fingerprint = 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
 383   │ uid       [ultimate] Daniel Ellsberg <ellsberg@example.org>
 384   │ sub   rsa2048/72A4D018 2014-11-04
 385   └────
 386
 387   Another common operation is to sign a key.  /gpg/ can do this directly
 388   from the command line by giving the fingerprint of the to-be-signed
 389   key:
 390
 391   ┌────
 392   │ $ gpg2 --quick-sign-key  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
 393   │
 394   │ pub  rsa2048/BD19AC1C
 395   │      created: 2014-11-04  expires: never       usage: SC
 396   │      trust: ultimate      validity: ultimate
 397   │  Primary key fingerprint: 15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C
 398   │
 399   │      Daniel Ellsberg <ellsberg@example.org>
 400   └────
 401
 402   In case the key has already been signed, the command prints a note and
 403   exits with success.  In case you want to check that it really worked,
 404   use `=--check-sigs' as usual:
 405
 406   ┌────
 407   │ $ gpg2 --check-sigs  '15CB 723E 2000 A1A8 2505  F3B7 CC00 B501 BD19 AC1C'
 408   │ gpg: checking the trustdb
 409   │ gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
 410   │ gpg: depth: 0  valid:   6  signed:   1  trust: 0-, 0q, 0n, 0m, 0f, 6u
 411   │ pub   rsa2048/BD19AC1C 2014-11-04
 412   │ uid       [  full  ] Daniel Ellsberg <ellsberg@example.org>
 413   │ sig!3        BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
 414   │ sig!         68FD0088 2014-11-04  Glenn Greenwald <glenn@example.org>
 415   │ sub   rsa2048/72A4D018 2014-11-04
 416   │ sig!         BD19AC1C 2014-11-04  Daniel Ellsberg <ellsberg@example.org>
 417   └────
 418
 419
 420   The fingerprint may also be given without the spaces in which case
 421   there is no need for the quotes.  If you want to sign only certain
 422   user ids of a key, list those user id verbatim after the fingerprint.
 423   To create a non-exportable key signature, use the command
 424   `--quick-lsign-key' instead.
 425
 426   Since version 2.1.4 it possible to directly add another user id to an
 427   existing key:
 428
 429   ┌────
 430   │ $ gpg2 -k 8CFDE12197965A9A
 431   │ pub   ed25519/8CFDE12197965A9A 2014-08-19
 432   │ uid               [ unknown] EdDSA sample key 1
 433   │ $ gpg2 --quick-adduid 8CFDE12197965A9A 'Sample 2 <me@example.org>'
 434   │ $ gpg2 -k 8CFDE12197965A9A
 435   │ pub   ed25519/8CFDE12197965A9A 2014-08-19
 436   │ uid               [ unknown] Sample 2 <me@example.org>
 437   │ uid               [ unknown] EdDSA sample key 1
 438   └────
 439
 440
 441 1.6 Improved Pinentry support
 442 ─────────────────────────────
 443
 444   When using a recent Pinentry module (0.90, GTK+ variant), the
 445   gpg-agent will not anymore show two separate Pinentry dialogs to enter
 446   a new passphrase and later to confirm the new passphrase.  Instead the
 447   first dialog also has the confirm/repeat entry and internally checks
 448   whether they match.
 449
 450   With any Pinentry version the several separate dialogs to inform and
 451   ask for confirmation about questionable properties of a new passphrase
 452   (e.g. length, only alpha letters) have been combined into one dialog
 453   to show all non-asserted constraints at once.
 454
 455   The GTK+ Pinentry does now allow pasting of values into the entries.
 456   Copying them from the entries is still inhibited on purpose.
 457   Depending on the system, the option `no-grab' may be required for in
 458   the `gpg-agent.conf' file to actually make use of the paste feature.
 459
 460
 461 1.7 Auto-start of the gpg-agent
 462 ───────────────────────────────
 463
 464   The /gpg-agent/ is the central part of the GnuPG system.  It takes
 465   care of all private (secret) keys and if required diverts operations
 466   to a smartcard or other token.  It also provides support for the
 467   Secure Shell by implementing the ssh-agent protocol.
 468
 469   The classic way to run /gpg-agent/ on Unix systems is by launching it
 470   at login time and use an environment variable (`GPG_AGENT_INFO') to
 471   tell the other GnuPG modules how to connect to the agent.  However,
 472   correctly managing the start up and this environment variable is
 473   cumbersome so that that an easier method is required.  Since GnuPG
 474   2.0.16 the `--use-standard-socket' option already allowed to start the
 475   agent on the fly; however the environment variable was still required.
 476
 477   With GnuPG 2.1 the need of `GPG_AGENT_INFO' has been completely
 478   removed and the variable is ignored.  Instead a fixed Unix domain
 479   socket named `S.gpg-agent' in the GnuPG home directory (by default
 480   `~/.gnupg') is used.  The agent is also started on demand by all tools
 481   requiring services from the agent.
 482
 483   If the option `--enable-ssh-support' is used the auto-start mechanism
 484   does not work because /ssh/ does not know about this mechanism.
 485   Instead it is required that the environment variable `SSH_AUTH_SOCK'
 486   is set to the `S.gpg-agent.ssh' socket in the GnuPG home directory.
 487   Further /gpg-agent/ must be started: Either by using a GnuPG command
 488   which implicitly starts /gpg-agent/ or by using `gpgconf --launch
 489   gpg-agent' to explicitly start it if not yet done.
 490
 491
 492 1.8 Duplicate long key id fixes
 493 ───────────────────────────────
 494
 495   A deficit of the OpenPGP protocol is that signatures carry only a
 496   limited indication on which public has been used to create a
 497   signature.  Thus a verification engine may only use this “long key id”
 498   to look up the the key in its own store or from a public keyserver.
 499   Unfortunately it has now become possible to create a key with a long
 500   key id matching the key id of another key.  Importing a key with a
 501   long key id already used by another key in gpg’s local key store was
 502   not possible due to checks done on import.  Now, if the “wrong” key
 503   has been imported first /gpg/ would not allow to later import the
 504   second “correct” key.  This problem has been fixed in 2.1 by allowing
 505   the import and by doing trial verification against all matching keys.
 506
 507
 508 1.9 Enhanced Dirmngr
 509 ────────────────────
 510
 511   Before version 2.1, /gpg/ used so-called keyserver helpers to access
 512   the OpenPGP keyservers.  A problem with that is that they are short
 513   living processes which are not able to keep a state.  With 2.1, the
 514   formerly separate package Dirmngr (which was separate due to copyright
 515   assignment reasons) has been integrated into GnuPG.
 516
 517   In the past /dirmngr/ was only used by /gpgsm/ for X.509 (S/MIME) CRL
 518   and OCSP handling.  Being a proper part of GnuPG /dirmngr/ does now
 519   also care about accessing OpenPGP keyservers.  This make its easier to
 520   debug problems with the keyservers and to exchange additional
 521   information about the keyserver between /gpg/ and /dirmngr/.  It will
 522   eventually also be possible to run background tasks to refresh keys.
 523
 524   Although the ability to start /dirmngr/ as a system service is still
 525   available, this is not anymore recommended and instead /dirmngr/ is
 526   now by default started on-demand, very similar to /gpg-agent/.
 527
 528
 529 1.10 Better keyserver pool support
 530 ──────────────────────────────────
 531
 532   For load balancing reasons, keyservers are organized in pools to
 533   enable instant round-robin DNS assignment of random keyservers.  A
 534   problem with that approach is that the DNS resolver is not aware of
 535   the state of the keyserver.  If a keyserver has gone down or a routing
 536   problems occurs, /gpg/ and its keyserver helpers were not ware of it
 537   and would try over and over to use the same, dead, keyserver up until
 538   the DNS information expires and a the DNS resolver assigned a new
 539   server from the pool.
 540
 541   The new /dirmngr/ in GnuPG does not use the implicit round-robin of
 542   the DNS resolver but uses its own DNS look up and keeps an internal
 543   table of all hosts from the pool along with the encountered aliveness
 544   state.  Thus after a failure (timeout) of a request, /dirmngr/ flags a
 545   host as dead and randomly selects another one from the pool.  After a
 546   few hours the flag is removed so that the host will be tried again.
 547   It is also possible to mark a specif host from a pool explicitly as
 548   dead so that it won’t be used in future.  To interact with the
 549   /dirmngr/ the `gpg-connect-agent' tool is used:
 550
 551   ┌────
 552   │ $ gpg-connect-agent --dirmngr 'help keyserver' /bye
 553   │ $ gpg-connect-agent --dirmngr 'keyserver --hosttable' /bye
 554   └────
 555
 556   The first command prints a help screen for the keyserver command and
 557   the second command prints the current host table.
 558
 559
 560 1.11 Faster keyring format
 561 ──────────────────────────
 562
 563   The format GnuPG has always used for the public keyring is actually a
 564   slightly extended version of the on-the-wire format for OpenPGP key
 565   exchange.  This format is quite inflexible to work with when random
 566   access to keys in the keyring is required.  In fact /gpg/ always
 567   parsed all keys in the keyring until it encountered the desired one.
 568   With a large keyring (more than a few thousand keys) this could be
 569   quite slow.
 570
 571   From its very beginning /gpgsm/ has used a different format to store
 572   public keys (certificates) which we call a /keybox/. That file format
 573   carries meta information about the stored keys and thus allows
 574   searching without actually parsing the key and computing fingerprints
 575   and such.  The /keybox/ format has been designed protocol independent
 576   and with 2.1 support for OpenPGP keys has been added.  Random access
 577   to the keys is now really fast and keyrings with 30000 keys and more
 578   are now easily possible.  That change also enables us to easily
 579   introduce other storage methods
 580
 581   If no `pubring.gpg' is found, /gpg/ defaults to the new /keybox/
 582   format and creates a `pubring.kbx' keybox file.  If such a keybox file
 583   already exists, for example due to the use of /gpgsm/, it will also be
 584   used for OpenPGP keys.  However, if a `pubring.gpg' is found and no
 585   keybox file with OpenPGP keys exists, the old `pubring.gpg' will be
 586   used.  Take care: GnuPG versions before 2.1 will always use the
 587   `pubring.gpg' file and not know anything about keys stored in the
 588   keybox file.
 589
 590   To convert an existing `pubring.gpg' file to the keybox format, you
 591   first backup the ownertrust values, then rename the file to (for
 592   example) `publickeys', so it won’t be recognized by any GnuPG version,
 593   then run import, and finally restore the ownertrust values:
 594
 595   ┌────
 596   │ $ cd ~/.gnupg
 597   │ $ gpg --export-ownertrust >otrust.lst
 598   │ $ mv pubring.gpg publickeys
 599   │ $ gpg2 --import-options import-local-sigs --import publickeys
 600   │ $ gpg2 --import-ownertrust otrust.lst
 601   └────
 602
 603   You may then rename the `publickeys' file back so that it can be used
 604   by older GnuPG versions.  Remember that in this case you have two
 605   independent copies of the public keys.  The ownertrust values are kept
 606   by all gpg versions in the file `trustdb.gpg' but the above
 607   precautions need to be taken to keep them over an import.
 608
 609
 610 1.12 Auto-generated revocation certificates
 611 ───────────────────────────────────────────
 612
 613   This version creates an ASCII armored revocation certificate for each
 614   generated keypair and stores that certificate in a file named after
 615   the fingerprint of the key in the `openpgp-revocs.d' directory below
 616   the GnuPG home directory.  Brief instructions on how to use this
 617   revocation certificate are put at the top of the file.
 618
 619
 620 1.13 Improved card support
 621 ──────────────────────────
 622
 623   The /scdaemon/, which is responsible for accessing smardcards and
 624   other tokens, has received many updates.  In particular plugable USB
 625   readers with a fixed card now work smoothless and similar to standard
 626   readers.  The latest features of the [gnuk] token are supported.  Code
 627   for the SmartCard-HSM has been added.  More card readers with a PIN
 628   pad are supported.  The internal CCID driver does now also work with
 629   certain non-auto configuration equipped readers.
 630
 631
 632   [gnuk] http://www.fsij.org/doc-gnuk/
 633
 634
 635 1.14 New format for key listings
 636 ────────────────────────────────
 637
 638   Due to the introduction of ECC keys the old format to list keys was
 639   not anymore suitable.  In particular, the length of an ECC key is
 640   defined but its expressiveness is limited without the other parameters
 641   of the curve.  The common way to describe an ECC key is by using the
 642   assigned name of its curve.  To allow for a common description we now
 643   either use the algorithm name with appended key length or use the name
 644   of the curve:
 645
 646   ┌────
 647   │ pub   2048D/1E42B367 2007-12-31 [expires: 2018-12-31]
 648   │ pub   dsa2048/1E42B367 2007-12-31 [expires: 2018-12-31]
 649   │ pub   ed25519/0AA914C9 2014-10-18
 650   └────
 651
 652   The first two lines show the same key in the old format and in the new
 653   format.  The third line shows an example of an ECC key using the
 654   ed25519 curve.
 655
 656   As a further change the validity of a key is now shown by default;
 657   that is `show-uid-validity' is implicitly used for the
 658   `--list-options'.
 659
 660   The annotated key listing produced by the `--with-colons' options did
 661   not change.  However a couple of new fields have been added, for
 662   example if the new option `--with-secret-' is used the “S/N of a token
 663   field” indicates the presence of a secret key even in a public key
 664   listing.  This option is supported by recent [GPGME] versions and
 665   makes writing of key manager software easier.
 666
 667
 668   [GPGME] https://gnupg.org/related_software/gpgme/
 669
 670
 671 1.15 Support for Putty
 672 ──────────────────────
 673
 674   On Windows the new option `--enable-putty-support' allows gpg-agent to
 675   act as a replacement for [Putty]’s authentication agent /Pageant/.  It
 676   is the Windows counterpart for the `--enable-ssh-support' option as
 677   used on Unix.
 678
 679
 680   [Putty] http://www.chiark.greenend.org.uk/~sgtatham/putty/
 681
 682
 683 1.16 Export of SSH public keys
 684 ──────────────────────────────
 685
 686   The new command `--export-ssh-key' makes it easy to export an /ssh/
 687   public key in the format used for ssh’s `authorized_keys' file.  By
 688   default the command exports the newest subkey with an authorization
 689   usage flags.  A special syntax can be used to export other subkeys.
 690   This command is available since 2.1.11 and replaces the former debug
 691   utility /gpgkey2ssh/.
 692
 693
 694 1.17 Improved X.509 certificate creation
 695 ────────────────────────────────────────
 696
 697   In addition to an improved certificate signing request menu, it is now
 698   possible to create a self-signed certificate using the interactive
 699   menu of /gpgsm/.
 700
 701   In batch mode the certificate creation dialog can now be controlled by
 702   a parameter file with several new keywords.  Such a parameter file
 703   allows the creation of arbitrary X.509 certificates similar to what
 704   can be done with /openssl/.  It may this be used as the base for a CA
 705   software.  For details see the “CSR and certificate creation” section
 706   in the manual.
 707
 708   The new commands `--export-secret-key-p8' and –export-secret-key-raw=
 709   may be used to export a secret key directly in PKCS#8 or PKCS#1
 710   format.  Thus X.509 certificates for TLS use may be managed by /gpgsm/
 711   and directly exported in a format suitable for OpenSSL based servers.
 712
 713
 714 1.18 Scripts to create a Windows installer
 715 ──────────────────────────────────────────
 716
 717   GnuPG now comes with the /speedo/ build system which may be used to
 718   quickly download and build GnuPG and all its direct dependencies on a
 719   decent Unix system.  See the README file for more instructions.
 720
 721   The very same script may also be used to build a complete NSIS based
 722   installer for Windows using the mingw-w64 cross-compiler toolchain.
 723   That installer will feature GnuPG proper, GPA as graphical frontend,
 724   and GpgEX as a Windows Explorer extension.  GnuPG needs to be unpacked
 725   and from the top source directory you run this command
 726
 727   ┌────
 728   │ make -f build-aux/speedo.mk w32-installer
 729   └────
 730
 731   This command downloads all direct dependencies, checks the signatures
 732   using the GnuPG version from the build system (all Linux distros
 733   feature a suitable GnuPG tool), builds everything from source, and
 734   uses NSIS to create the installer.  Although this sounds easy, some
 735   experience in setting up a development machine is still required.
 736   Some versions of the toolchain exhibit bugs and thus your mileage may
 737   vary.  See the [Wiki] for more info.
 738
 739   Support for keyserver access over TLS is currently not available but
 740   will be added with one of the next point releases.
 741
 742   [Wiki] https://wiki.gnupg.org/Build2.1_Windows
 743
 744
 745   # Copyright 2014--2016 The GnuPG Project.
 746   # This work is licensed under the Creative Commons
 747   # Attribution-ShareAlike 4.0 International License.  To view a copy of
 748   # this license, visit http://creativecommons.org/licenses/by-sa/4.0/
 749   # or send a letter to Creative Commons, PO Box 1866, Mountain View, CA
 750   # 94042, USA.
 751   #
 752   # The canonical source for this article can be found in the gnupg-doc
 753   # git repository as web/faq/whats-new-in-2.1.org.