mirror of
git://git.gnupg.org/gnupg.git
synced 2024-12-24 10:39:57 +01:00
203 lines
7.9 KiB
Plaintext
203 lines
7.9 KiB
Plaintext
|
GnuPG 1.4 Highlights
|
||
|
====================
|
||
|
|
||
|
This is a brief overview of the changes between the GnuPG 1.2 series
|
||
|
and the new GnuPG 1.4 series. To read the full list of highlights for
|
||
|
each revision that led up to 1.4, see the NEWS file in the GnuPG
|
||
|
distribution. This document is based on the NEWS file, and is thus
|
||
|
the highlights of the highlights.
|
||
|
|
||
|
When upgrading, note that RFC-2440, the OpenPGP standard, is currently
|
||
|
being revised. Most of the revisions in the latest draft (2440bis-12)
|
||
|
have already been incorporated into GnuPG 1.4.
|
||
|
|
||
|
|
||
|
Algorithm Changes
|
||
|
-----------------
|
||
|
|
||
|
OpenPGP supports many different algorithms for encryption, hashing,
|
||
|
and compression, and taking into account the OpenPGP revisions, GnuPG
|
||
|
1.4 supports a slightly different algorithm set than 1.2 did.
|
||
|
|
||
|
The SHA256, SHA384, and SHA512 hashes are now supported for read and
|
||
|
write.
|
||
|
|
||
|
The BZIP2 compression algorithm is now supported for read and write.
|
||
|
|
||
|
Due to the recent successful attack on the MD5 hash algorithm
|
||
|
(discussed in <http://www.rsasecurity.com/rsalabs/node.asp?id=2738>,
|
||
|
among other places), MD5 is deprecated for OpenPGP use. It is still
|
||
|
allowed in GnuPG 1.4 for backwards compatibility, but a warning is
|
||
|
given when it is used.
|
||
|
|
||
|
The TIGER/192 hash is no longer available. This should not be
|
||
|
interpreted as a statement as to the quality of TIGER/192 - rather,
|
||
|
the revised OpenPGP standard removes support for several unused or
|
||
|
mostly unused hashes, and TIGER/192 was one of them.
|
||
|
|
||
|
Similarly, Elgamal signatures and the Elgamal signing key type have
|
||
|
been removed from the OpenPGP standard, and thus from GnuPG. Please
|
||
|
do not confuse Elgamal signatures with DSA or DSS signatures or with
|
||
|
Elgamal encryption. Elgamal signatures were very rarely used and were
|
||
|
not supported in any product other than GnuPG. Elgamal encryption was
|
||
|
and still is part of OpenPGP and GnuPG.
|
||
|
|
||
|
Very old (pre-1.0) versions of GnuPG supported a nonstandard (contrary
|
||
|
to OpenPGP) Elgamal key type. While no recent version of GnuPG
|
||
|
permitted the generation of such keys, GnuPG 1.2 could still use them.
|
||
|
GnuPG 1.4 no longer allows the use of these keys or the (also
|
||
|
nonstandard) messages generated using them.
|
||
|
|
||
|
At build time, it is possible to select which algorithms will be built
|
||
|
into GnuPG. This can be used to build a smaller program binary for
|
||
|
embedded uses where space is tight.
|
||
|
|
||
|
|
||
|
Keyserver Changes
|
||
|
-----------------
|
||
|
|
||
|
GnuPG 1.4 does all keyserver operations via plugin or helper
|
||
|
applications. This allows the main GnuPG program to be smaller and
|
||
|
simpler. People who package GnuPG for various reasons have the
|
||
|
flexibility to include or leave out support for any keyserver type as
|
||
|
desired.
|
||
|
|
||
|
Support for fetching keys via HTTP and finger has been added. This is
|
||
|
mainly useful for setting a preferred keyserver URL like
|
||
|
"http://www.jabberwocky.com/key.asc". or "finger:wk@g10code.com".
|
||
|
|
||
|
The LDAP keyserver helper now supports storing, retrieving, and
|
||
|
searching for keys in both the old NAI "LDAP keyserver" as well as the
|
||
|
more recent method to store OpenPGP keys in standard LDAP servers.
|
||
|
This is compatible with the storage schema that PGP uses, so both
|
||
|
products can interoperate with the same LDAP server.
|
||
|
|
||
|
The LDAP keyserver helper is compatible with the PGP company's new
|
||
|
"Global Directory" service.
|
||
|
|
||
|
If the LDAP library you use supports LDAP-over-TLS and LDAPS, then
|
||
|
GnuPG detects this and supports them as well. Note that using TLS or
|
||
|
LDAPS does not improve the security of GnuPG itself, but may be useful
|
||
|
in certain key distribution scenarios.
|
||
|
|
||
|
HTTP Basic authentication is now supported for all HKP and HTTP
|
||
|
keyserver functions, either through a proxy or via direct access.
|
||
|
|
||
|
The HKP keyserver plugin supports the new machine-readable key
|
||
|
listing format for those keyservers that provide it.
|
||
|
|
||
|
IPv6 is supported for HKP and HTTP keyserver access.
|
||
|
|
||
|
When using a HKP keyserver with multiple DNS records (such as
|
||
|
subkeys.pgp.net which has the addresses of multiple servers around the
|
||
|
world), all DNS address records are tried until one succeeds. This
|
||
|
prevents a single down server in the rotation from stopping access.
|
||
|
|
||
|
DNS SRV records are used in HKP keyserver lookups to allow
|
||
|
administrators to load balance and select keyserver ports
|
||
|
automatically.
|
||
|
|
||
|
Timeout support has been added to the keyserver plugins. This allows
|
||
|
users to set an upper limit on how long to wait for the keyserver
|
||
|
before giving up.
|
||
|
|
||
|
|
||
|
Preferred Keyserver URL
|
||
|
-----------------------
|
||
|
|
||
|
Preferred keyserver support has been added. Users may set a preferred
|
||
|
keyserver via the --edit-key command "keyserver". If the
|
||
|
--keyserver-option honor-keyserver-url is set (and it is by default),
|
||
|
then the preferred keyserver is used when refreshing that key with
|
||
|
--refresh-keys.
|
||
|
|
||
|
The --sig-keyserver-url option can be used to inform signature
|
||
|
recipients where the signing key can be downloaded. When verifying
|
||
|
the signature, if the signing key is not present, and the keyserver
|
||
|
options honor-keyserver-url and auto-key-retrieve are set, this URL
|
||
|
will be used to retrieve the key.
|
||
|
|
||
|
|
||
|
Trust Signatures
|
||
|
----------------
|
||
|
|
||
|
GnuPG 1.4 supports OpenPGP trust signatures, which allow a user to
|
||
|
specify the trust level and distance from the user along with the
|
||
|
signature so users can delegate different levels of certification
|
||
|
ability to other users, possibly restricted by a regular expression on
|
||
|
the user ID.
|
||
|
|
||
|
|
||
|
Trust Models
|
||
|
------------
|
||
|
|
||
|
GnuPG 1.4 supports several ways of looking at trust:
|
||
|
|
||
|
Classic - The classic PGP trust model, where people sign each others
|
||
|
keys and thus build up an assurance (called "validity") that
|
||
|
the key belongs to the right person. This was the default
|
||
|
trust model in GnuPG 1.2.
|
||
|
|
||
|
Always - Bypass all trust checks, and make all keys fully valid.
|
||
|
|
||
|
Direct - Users may set key validity directly.
|
||
|
|
||
|
PGP - The PGP 7 and 8 behavior which combines Classic trust with trust
|
||
|
signatures overlaid on top. This is the default trust model in
|
||
|
GnuPG 1.4.
|
||
|
|
||
|
|
||
|
The OpenPGP Smartcard
|
||
|
---------------------
|
||
|
|
||
|
GnuPG 1.4 supports the OpenPGP smartcard
|
||
|
(<http://www.g10code.de/p-card.html>)
|
||
|
|
||
|
Secret keys may be kept fully or partially on the smartcard. The
|
||
|
smartcard may be used for primary keys or subkeys.
|
||
|
|
||
|
|
||
|
Other Interesting New Features
|
||
|
------------------------------
|
||
|
|
||
|
For those using Security-Enhanced Linux <http://www.nsa.gov/selinux/>,
|
||
|
the configure option --enable-selinux-support prevents GnuPG from
|
||
|
processing its own files (i.e. reading the secret keyring for
|
||
|
something other than getting a secret key from it). This simplifies
|
||
|
writing ACLs for the SELinux kernel.
|
||
|
|
||
|
Readline support is now available at all prompts if the system
|
||
|
provides a readline library.
|
||
|
|
||
|
GnuPG can now create messages that can be decrypted with either a
|
||
|
passphrase or a secret key. These messages may be generated with
|
||
|
--symmetric --encrypt or --symmetric --sign --encrypt.
|
||
|
|
||
|
--list-options and --verify-options allow the user to customize
|
||
|
exactly what key listings or signature verifications look like,
|
||
|
enabling or disabling things such as photo display, preferred
|
||
|
keyserver URL, calculated validity for each user ID, etc.
|
||
|
|
||
|
The --primary-keyring option designates the keyring that the user
|
||
|
wants new keys imported into.
|
||
|
|
||
|
The --hidden-recipient (or -R) command encrypts to a user, but hides
|
||
|
the identity of that user. This is the same functionality as
|
||
|
--throw-keyid, but can be used on a per-user basis.
|
||
|
|
||
|
Full algorithm names (e.g. "3DES", "SHA1", "ZIP") can now be used
|
||
|
interchangeably with the short algorithm names (e.g. "S2", "H2", "Z1")
|
||
|
anywhere algorithm names are used in GnuPG.
|
||
|
|
||
|
The --keyid-format option selects short (99242560), long
|
||
|
(DB698D7199242560), 0xshort (0x99242560), or 0xlong
|
||
|
(0xDB698D7199242560) key ID displays. This lets users tune the
|
||
|
display to what they prefer.
|
||
|
|
||
|
While it is not recommended for extended periods, it is possible to
|
||
|
run both GnuPG 1.2.x and GnuPG 1.4 during the transition. To aid in
|
||
|
this, GnuPG 1.4 tries to load a config file suffixed with its version
|
||
|
before it loads the default config file. For example, 1.4 will try
|
||
|
for gpg.conf-1.4 and gpg.conf-1 before falling back to the regular
|
||
|
gpg.conf file.
|