doc/highlights-1.4.txt

   1 GnuPG 1.4 Highlights
   2 ====================
   3
   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.
   9
  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.
  13
  14
  15 Algorithm Changes
  16 -----------------
  17
  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.
  21
  22 The SHA256, SHA384, and SHA512 hashes are now supported for read and
  23 write.
  24
  25 The BZIP2 compression algorithm is now supported for read and write.
  26
  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.
  32
  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.
  37
  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.
  44
  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.
  50
  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.
  54
  55
  56 Keyserver Changes
  57 -----------------
  58
  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
  63 desired.
  64
  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".
  68
  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.
  74
  75 The LDAP keyserver helper is compatible with the PGP company's new
  76 "Global Directory" service.
  77
  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.
  82
  83 HTTP Basic authentication is now supported for all HKP and HTTP
  84 keyserver functions, either through a proxy or via direct access.
  85
  86 The HKP keyserver plugin supports the new machine-readable key
  87 listing format for those keyservers that provide it.
  88
  89 IPv6 is supported for HKP and HTTP keyserver access.
  90
  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.
  95
  96 DNS SRV records are used in HKP keyserver lookups to allow
  97 administrators to load balance and select keyserver ports
  98 automatically.
  99
 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
 102 before giving up.
 103
 104
 105 Preferred Keyserver URL
 106 -----------------------
 107
 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
 112 --refresh-keys.
 113
 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.
 119
 120
 121 Trust Signatures
 122 ----------------
 123
 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
 128 the user ID.
 129
 130
 131 Trust Models
 132 ------------
 133
 134 GnuPG 1.4 supports several ways of looking at trust:
 135
 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.
 140
 141 Always - Bypass all trust checks, and make all keys fully valid.
 142
 143 Direct - Users may set key validity directly.
 144
 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
 147       GnuPG 1.4.
 148
 149
 150 The OpenPGP Smartcard
 151 ---------------------
 152
 153 GnuPG 1.4 supports the OpenPGP smartcard
 154 (<http://www.g10code.de/p-card.html>)
 155
 156 Secret keys may be kept fully or partially on the smartcard.  The
 157 smartcard may be used for primary keys or subkeys.
 158
 159
 160 Other Interesting New Features
 161 ------------------------------
 162
 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.
 168
 169 Readline support is now available at all prompts if the system
 170 provides a readline library.
 171
 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.
 175
 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.
 180
 181 The --primary-keyring option designates the keyring that the user
 182 wants new keys imported into.
 183
 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.
 187
 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.
 191
 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.
 196
 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
 202 gpg.conf file.