4
This is a brief overview of the changes between the GnuPG 1.2 series
5
and the new GnuPG 1.4 series. To read the full list of highlights for
6
each revision that led up to 1.4, see the NEWS file in the GnuPG
7
distribution. This document is based on the NEWS file, and is thus
8
the highlights of the highlights.
10
When upgrading, note that RFC-2440, the OpenPGP standard, is currently
11
being revised. Most of the revisions in the latest draft (2440bis-12)
12
have already been incorporated into GnuPG 1.4.
18
OpenPGP supports many different algorithms for encryption, hashing,
19
and compression, and taking into account the OpenPGP revisions, GnuPG
20
1.4 supports a slightly different algorithm set than 1.2 did.
22
The SHA256, SHA384, and SHA512 hashes are now supported for read and
25
The BZIP2 compression algorithm is now supported for read and write.
27
Due to the recent successful attack on the MD5 hash algorithm
28
(discussed in <http://www.rsasecurity.com/rsalabs/node.asp?id=2738>,
29
among other places), MD5 is deprecated for OpenPGP use. It is still
30
allowed in GnuPG 1.4 for backwards compatibility, but a warning is
31
given when it is used.
33
The TIGER/192 hash is no longer available. This should not be
34
interpreted as a statement as to the quality of TIGER/192 - rather,
35
the revised OpenPGP standard removes support for several unused or
36
mostly unused hashes, and TIGER/192 was one of them.
38
Similarly, Elgamal signatures and the Elgamal signing key type have
39
been removed from the OpenPGP standard, and thus from GnuPG. Please
40
do not confuse Elgamal signatures with DSA or DSS signatures or with
41
Elgamal encryption. Elgamal signatures were very rarely used and were
42
not supported in any product other than GnuPG. Elgamal encryption was
43
and still is part of OpenPGP and GnuPG.
45
Very old (pre-1.0) versions of GnuPG supported a nonstandard (contrary
46
to OpenPGP) Elgamal key type. While no recent version of GnuPG
47
permitted the generation of such keys, GnuPG 1.2 could still use them.
48
GnuPG 1.4 no longer allows the use of these keys or the (also
49
nonstandard) messages generated using them.
51
At build time, it is possible to select which algorithms will be built
52
into GnuPG. This can be used to build a smaller program binary for
53
embedded uses where space is tight.
59
GnuPG 1.4 does all keyserver operations via plugin or helper
60
applications. This allows the main GnuPG program to be smaller and
61
simpler. People who package GnuPG for various reasons have the
62
flexibility to include or leave out support for any keyserver type as
65
Support for fetching keys via HTTP and finger has been added. This is
66
mainly useful for setting a preferred keyserver URL like
67
"http://www.jabberwocky.com/key.asc". or "finger:wk@g10code.com".
69
The LDAP keyserver helper now supports storing, retrieving, and
70
searching for keys in both the old NAI "LDAP keyserver" as well as the
71
more recent method to store OpenPGP keys in standard LDAP servers.
72
This is compatible with the storage schema that PGP uses, so both
73
products can interoperate with the same LDAP server.
75
The LDAP keyserver helper is compatible with the PGP company's new
76
"Global Directory" service.
78
If the LDAP library you use supports LDAP-over-TLS and LDAPS, then
79
GnuPG detects this and supports them as well. Note that using TLS or
80
LDAPS does not improve the security of GnuPG itself, but may be useful
81
in certain key distribution scenarios.
83
HTTP Basic authentication is now supported for all HKP and HTTP
84
keyserver functions, either through a proxy or via direct access.
86
The HKP keyserver plugin supports the new machine-readable key
87
listing format for those keyservers that provide it.
89
IPv6 is supported for HKP and HTTP keyserver access.
91
When using a HKP keyserver with multiple DNS records (such as
92
subkeys.pgp.net which has the addresses of multiple servers around the
93
world), all DNS address records are tried until one succeeds. This
94
prevents a single down server in the rotation from stopping access.
96
DNS SRV records are used in HKP keyserver lookups to allow
97
administrators to load balance and select keyserver ports
100
Timeout support has been added to the keyserver plugins. This allows
101
users to set an upper limit on how long to wait for the keyserver
105
Preferred Keyserver URL
106
-----------------------
108
Preferred keyserver support has been added. Users may set a preferred
109
keyserver via the --edit-key command "keyserver". If the
110
--keyserver-option honor-keyserver-url is set (and it is by default),
111
then the preferred keyserver is used when refreshing that key with
114
The --sig-keyserver-url option can be used to inform signature
115
recipients where the signing key can be downloaded. When verifying
116
the signature, if the signing key is not present, and the keyserver
117
options honor-keyserver-url and auto-key-retrieve are set, this URL
118
will be used to retrieve the key.
124
GnuPG 1.4 supports OpenPGP trust signatures, which allow a user to
125
specify the trust level and distance from the user along with the
126
signature so users can delegate different levels of certification
127
ability to other users, possibly restricted by a regular expression on
134
GnuPG 1.4 supports several ways of looking at trust:
136
Classic - The classic PGP trust model, where people sign each others
137
keys and thus build up an assurance (called "validity") that
138
the key belongs to the right person. This was the default
139
trust model in GnuPG 1.2.
141
Always - Bypass all trust checks, and make all keys fully valid.
143
Direct - Users may set key validity directly.
145
PGP - The PGP 7 and 8 behavior which combines Classic trust with trust
146
signatures overlaid on top. This is the default trust model in
150
The OpenPGP Smartcard
151
---------------------
153
GnuPG 1.4 supports the OpenPGP smartcard
154
(<http://www.g10code.de/p-card.html>)
156
Secret keys may be kept fully or partially on the smartcard. The
157
smartcard may be used for primary keys or subkeys.
160
Other Interesting New Features
161
------------------------------
163
For those using Security-Enhanced Linux <http://www.nsa.gov/selinux/>,
164
the configure option --enable-selinux-support prevents GnuPG from
165
processing its own files (i.e. reading the secret keyring for
166
something other than getting a secret key from it). This simplifies
167
writing ACLs for the SELinux kernel.
169
Readline support is now available at all prompts if the system
170
provides a readline library.
172
GnuPG can now create messages that can be decrypted with either a
173
passphrase or a secret key. These messages may be generated with
174
--symmetric --encrypt or --symmetric --sign --encrypt.
176
--list-options and --verify-options allow the user to customize
177
exactly what key listings or signature verifications look like,
178
enabling or disabling things such as photo display, preferred
179
keyserver URL, calculated validity for each user ID, etc.
181
The --primary-keyring option designates the keyring that the user
182
wants new keys imported into.
184
The --hidden-recipient (or -R) command encrypts to a user, but hides
185
the identity of that user. This is the same functionality as
186
--throw-keyid, but can be used on a per-user basis.
188
Full algorithm names (e.g. "3DES", "SHA1", "ZIP") can now be used
189
interchangeably with the short algorithm names (e.g. "S2", "H2", "Z1")
190
anywhere algorithm names are used in GnuPG.
192
The --keyid-format option selects short (99242560), long
193
(DB698D7199242560), 0xshort (0x99242560), or 0xlong
194
(0xDB698D7199242560) key ID displays. This lets users tune the
195
display to what they prefer.
197
While it is not recommended for extended periods, it is possible to
198
run both GnuPG 1.2.x and GnuPG 1.4 during the transition. To aid in
199
this, GnuPG 1.4 tries to load a config file suffixed with its version
200
before it loads the default config file. For example, 1.4 will try
201
for gpg.conf-1.4 and gpg.conf-1 before falling back to the regular
added
removed
doc/highlights-1.4.txt
