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