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