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