From dshaw at jabberwocky.com Sat Oct 11 01:16:43 2003 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Feb 23 12:43:34 2005 Subject: [Announce] GnuPG 1.3.3 released (development) Message-ID: <20031010231643.GA27126@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! The latest release from the development branch of GnuPG is ready for public consumption. This is a branch to create what will eventually become GnuPG 1.4. It will change with greater frequency than the 1.2.x "stable" branch, which will mainly be updated for bug fix reasons. The more GnuPG-familiar user is encouraged try this release (and the ones that will follow in the 1.3.x branch), and report back any problems to gnupg-devel@gnupg.org. In return, you get the latest code with the latest features. Feedback on the "show-validity" display changes is particularly appreciated. Is this additional information (seen in --list-keys or - --list-sigs when "--list-options show-validity" is set) helpful or confusing? Note that while this code is stable enough for many uses, it is still the development branch. Mission-critical applications should always use the 1.2.x stable branch. The files are available from: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.3.tar.gz (1667k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.3.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.2-1.3.3.diff.gz MD5 checksums for the files are: 328ed3ecd62e90b5f2903b211e7f920d gnupg-1.3.3.tar.gz a2558c5f06df52d2e501012c136e3c68 gnupg-1.3.3.tar.gz.sig 514ffb450766b13eb596978ac0d728e9 gnupg-1.3.2-1.3.3.diff.gz Noteworthy changes in version 1.3.3 (2003-10-10) - ------------------------------------------------ * Basic support for the OpenPGP card. New commands --card-status, --card-edit, --change-pin and the configuration options --reader-port, --ctapi-driver, --pcsc-driver, and --disable-ccid. * Full support for the SHA-256 hash has been added. * Support for the TIGER/192 hash has been dropped. This should not be interpreted as a statement as to the strength of TIGER/192 - rather, the upcoming revision to the OpenPGP standard removes support for several unused (or mostly unused) hashes. * Revoked or expired user IDs are now skipped when selecting keys for encryption. Specifying a key by the key ID overrides this check and allows the selection of any key. * Note that --no-mangle-dos-filenames is now the default. If you are upgrading from a 1.2.x version of GnuPG, and are running a very old version of Windows that has the 8.3 filename limit, you may need to change this. * Multiple "Comment:" lines in armored output are now allowed. * New --list-options option. This option takes a list of arguments that allows the user to customize exactly what key listings (including the --edit-key listing) look like, enabling or disabling things such as photo display, policy URL, preferred keyserver URL, or notation display, long or short keyIDs, calculated validity for each user ID, etc. See the manual for the complete list of list-options. * New --verify-options option. This option takes a list of arguments that allows the user to customize exactly what happens during signature verification, enabling or disabling things such as photo display, policy URL, preferred keyserver URL, or notation display, long or short keyIDs, calculated validity for each user ID, etc. See the manual for the complete list of verify-options. * New --sig-keyserver-url to embed a "where to get my key" subpacket into a signature. * The options --show-photos, --show-policy-url, --show-notation, and --show-keyring are all deprecated in favor of those arguments to --list-options and --verify-options. The new method is more flexible since a user can specify (for example) showing photos during sig verification, but not in key listings. * The complete fingerprint of the key that made a given key certification is now available in the --with-colons output. For technical reasons, this is only available when running with --no-sig-cache set. See doc/DETAILS for the specifics of this. * IPv6 support for HKP keyserver access. IPv6 for LDAP keyserver access is also supported, but is dependent on the LDAP library used. * To simplify running both the stable (1.2.x) and development (1.3.x) versions of GnuPG, the development version will try to load the options file gpg.conf-VERSION (e.g. gpg.conf-1.3.3 for this release) before falling back to the regular gpg.conf file. * Two new %-expandos for use in notation and policy URLs. "%g" expands to the fingerprint of the key making the signature (which might be a subkey), and "%p" expands to the fingerprint of the primary key that owns the key making the signature. * New "tru" record in --with-colons --list-keys listings. It shows the status of the trust database that was used to calculate the key validity in the listings. See doc/DETAILS for the specifics of this. * New REVKEYSIG status tag for --status-fd. It indicates a valid signature that was issued by a revoked key. See doc/DETAILS for the specifics of this. * A number of portability changes to make building GnuPG on less-common platforms easier. Happy Hacking, The GnuPG team (David, Stefan, Timo and Werner) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj+HPdsqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJNgUAoJ5XDJ0EAhMSiak1q1N49TLwfONAAJ4k A48KADjnIhrjLSGFZKjnZxmL1A== =UGcD -----END PGP SIGNATURE----- From mcoca at gnu.org Wed Oct 22 14:45:24 2003 From: mcoca at gnu.org (Miguel Coca) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] GPA 0.7.0 released Message-ID: <20031022124524.GA26390@mycroft> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, We are pleased to announce the release of GPA 0.7.0 GPA is a graphical frontend for the GNU Privacy Guard (GnuPG, http://www.gnupg.org). GPA can be used to encrypt, decrypt, and sign files, to verify signatures and to manage the private and public keys. GPA depends on the GnuPG Made Easy (GPGME) library, version 0.4.3 or later. This is a development release. Please be careful when using it on production keys. You can find the release here: ftp://ftp.gnupg.org/gcrypt/alpha/gpa/gpa-0.7.0.tar.gz ftp://ftp.gnupg.org/gcrypt/alpha/gpa/gpa-0.7.0.tar.gz.sig The MD5 checksums for this release are: 44cb60cba64a48837588ed27f8db08b2 gpa-0.7.0.tar.gz a6e414cce650597a24609cc374af4b4d gpa-0.7.0.tar.gz.sig Noteworthy changes in version 0.7.0 (2003-10-22) - ------------------------------------------------ * Long file operations no longer block GPA, so several operations can be run at the same time. This also means GPA does not freeze while an operation runs, leading to a more responsive interface. * The keyring editor now displays all the subkeys of the currently selected key. This is only visible if GPA is in advanced mode (available from the preferences dialog). * The capabilities of a key (certify, sign, encrypt) are now visible from the keyring editor. * The keyring editor can now sort keys by any column. By default, they are listed in the order they were imported into the keyring (i.e. the same order as "gpg --list-keys"). * The key list is now displayed while it is being filled, allowing for faster startup times. * A warning dialog is now displayed when an operation slows down due to gpg rebuilding the trust database. * Imports and exports from files and servers have been separated into different dialogs and menu options. * Invoking GPA with file names as arguments will open those files in the file manager. * Cosmetical and minor fixes to the file manager window. * GPA now remembers the brief/detailed setting view and restores it when GPA is started. * Removed all deprecated widgets. GPA is now pure GTK+ 2.2. * Fixed a hang on startup on PowerPC machines. Known problems in version 0.7.0 - -------------------------------- * Keyserver access now depends on the GnuPG's plugins themselves, instead of on the gpg executable. Therefore, these plugins must be installed for keyserver access to work: - LDAP keyservers require the gpgkeys_ldap plugin, which is automatically compiled along with gpg if the OpenLDAP libraries are available. - HKP keyserver access needs gpgkeys_hkp, which is provided by default along with GnuPG >= 1.3.0, and can be compiled for GnuPG 1.2.x by passing the --enable-external-hkp option to configure. * It's been reported that compiling a Win32 version of GPA is impossible right now, due to our dependence on GPGME. - -- Miguel Coca (mcoca@gnu.org) http://zipi.fi.upm.es/~e970095/ OpenPGP: E60A CBF4 5C6F 914E B6C1 C402 8C4D C7B6 27FC 3CA8 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/lnA5jE3Htif8PKgRAmqnAKCfWGVkw75zbSPiFCWqUL0Q/7rvzQCeM0eu nGC23qORYougNQfRS4EQ8II= =kLe5 -----END PGP SIGNATURE----- From mo at g10code.com Sat Nov 1 11:28:30 2003 From: mo at g10code.com (Moritz Schulte) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] Libgcrypt 1.1.44 released Message-ID: <871xss8jsh.fsf@hell.lan> We are pleased to announce version 1.1.44 of Libgcrypt, a general purpose cryptography library based on the code used in GnuPG. It may be downloaded from the following locations: ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt-1.1.44.tar.gz (823k) ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt-1.1.44.tar.gz.sig or as a diff to the last released version (1.1.43): ftp://ftp.gnupg.org/gcrypt/alpha/libgcrypt-1.1.43-1.1.44.diff.gz (57k) The files should soon appear on the mirrors listed at http://www.gnupg.org/mirrors.html. PLEASE USE THOSE MIRRORS! MD5 checksums are: c0d2da30a58c1f59604d8dbb702463c8 libgcrypt-1.1.44.tar.gz 80df28e5fc0435b36d273d0ae1b27320 libgcrypt-1.1.43-1.1.44.diff.gz Bug reports and requests for assistance should be sent to gcrypt-devel@gnupg.org. PLEASE NOTE: This is still marked as an unstable development version. The list of changes since version 1.1.43 is quite small: -------------------------------------------------------- * Enhancements to the prime number generation interface * Bug fixes, minor code cleanups -- Moritz Schulte From wk at gnupg.org Thu Nov 27 09:29:51 2003 From: wk at gnupg.org (Werner Koch) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] GnuPG's ElGamal signing keys compromised Message-ID: <87llq28b9c.fsf@alberti.g10code.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 GnuPG's ElGamal signing keys compromised ========================================== Summary ======= Phong Nguyen identified a severe bug in the way GnuPG creates and uses ElGamal keys for signing. This is a significant security failure which can lead to a compromise of almost all ElGamal keys used for signing. Note that this is a real world vulnerability which will reveal your private key within a few seconds. Please *take immediate action and revoke your ElGamal signing keys*. Furthermore you should take whatever measures necessary to limit the damage done for signed or encrypted documents using that key. Please do not send private mail in response to this message as I won't have the time to catch up with all the messages. The mailing list gnupg-users@gnupg.org is the best place to discuss this problem (please subscribe first so you don't need moderator approval [2]). Note that the standard keys as generated by GnuPG (DSA and ElGamal encryption) as well as RSA keys are NOT vulnerable. Note also that ElGamal signing keys cannot be generated without the use of a special flag to enable hidden options and even then overriding a warning message about this key type. See below for details on how to identify vulnerable keys. This message is signed using the usual GnuPG distribution key[1]. I apologize for this severe bug and all the problems resulting from it. Background: =========== For historic reasons [3], GnuPG permits creating ElGamal keys which are usable for both encryption and signing. It is even possible to have one key (the primary one) used for both operations. This is not considered good cryptographic practice, but is permitted by the OpenPGP standard. It was not anticipated that these keys would still be used for signing because they have several disadvantages: The signature is much larger than a RSA or DSA signature, verification and creation takes far longer and the use of ElGamal for signing has always been problematic due to a couple of cryptographic weaknesses when not done properly. Thus I have always dissuaded people from using ElGamal keys for signing; however they are still used and about 200 keys per year are generated and uploaded to the keyservers. In January 2000, as part of version 1.0.2, the GnuPG code was changed to create ElGamal keys which work more efficiently for encryption (selecting a smaller x secret exponent and using a smaller k for encryption). While making this change the problem with signing keys was accidentally introduced: the same small k for encryption was also used for signing. This can be used for a cryptographic attack to reveal the private key (i.e. the secret exponent x) if a signature made using that key is available. Such a signature is always available for primary ElGamal keys because signatures created with that key are used to bind the user ID and other material to the primary key (self-signatures). Even if the key was never used for signing documents it should be considered compromised. Note that this weakness does not apply to the far more common encrypt-only (type 16) ElGamal key as GnuPG does not permit signatures to be issued by this key type. Only the ElGamal sign+encrypt key (type 20) is affected and then only when used to make a signature with a GnuPG version 1.0.2 or later. Impact: ======= All ElGamal sign+encrypt keys (type 20) generated with GnuPG 1.0.2 or later must be considered compromised. Keys generated and used only with prior versions might still be safe but should ideally be revoked too. Note that even if an ElGamal sign+encrypt key was generated before GnuPG 1.0.2, using that key in GnuPG 1.0.2 or later to issue signatures will still compromise the key. Again, ElGamal encrypt-only keys (type 16) from any version of GnuPG are *not* affected. Solution: ========= Do not use *ElGamal sign+encrypt keys (type 20)*. Revoke all those keys immediately. Consider all material signed or encrypted with such a key as compromised. Forthcoming GnuPG versions will remove the ability to create such keys and the ability create ElGamal signatures. How to detect ElGamal type 20 keys: =================================== We have to distinguish between two cases: The primary key is ElGamal sign+encrypt versus just a subkey is ElGamal sign+encrypt. The first case requires immediate attention, like this one: $ gpg --list-keys xxxxxxxx pub 2048G/xxxxxxxx 2001-xx-xx Mallory such a key might be followed with additional "uid", "sig" or "sub" lines. Here an ElGamal sign+encrypt key is used and very likely created with GnuPG >= 1.0.2. The capital letter "G" indicates a ElGamal sign+encrypt key. REVOKE such a key immediately. The second case is about subkeys. Here is an example: $ gpg --list-keys 621CC013 pub 1024D/621CC013 1998-07-07 Werner Koch uid Werner Koch uid Werner Koch sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01] sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06] sub 1536R/23D2A63D 2002-07-30 [expires: 2003-12-31] This my usual working key, which is a standard GnuPG key with some additional subkeys added over time. It is a good example because one subkey was created as type 20 signing and encrypt ElGamal key. It is the second subkey: sub 1536G/B5A18FF4 1998-07-07 [expires: 2002-07-06] The capital letter "G" denotes such an possible compromised subkey whereas the first subkey: sub 1536g/ADF6A6E1 1999-02-20 [expires: 2002-11-01] is a standard encryption-only subkey as indicated by the small letter "g". That key is not affected. The keys denoted with this capital letter "G" should be REVOKED unless you are definitely sure those subkeys were never used to create a signatures with GnuPG >= 1.0.2. How to revoke a key: ==================== To create a revocation certificate for the entire key (primary and all subkeys), you do: gpg --gen-revoke your_keyid >foo.rev If you have lost access to your passphrase, hopefully you have a pre-manufactured revocation certificate (either on a floppy or printed on a sheet of paper) which you may the use instead of the above command. This revocation certificate should then be imported into GnuPG using: gpg --import mykey.asc gpg --keyserver subkeys.pgp.net --send-keys your_keyid If your primary key is not an ElGamal key, you might need to revoke a subkey. Note again that only type 20 ElGamal keys (denoted by a capital letter "G") require revocation - the standard ElGamal encrypt-only key (small g) is perfectly fine. Use gpg's edit command like this: $ gpg --edit-key xyzxyzxy The key listing will be shown. Select the subkey you want to revoke, using the command "key 2" (or whatever subkey it is) and then enter the command "revkey" and follow the prompts. Continue then with an export as described above. How many keys are affected? =========================== I can't tell for sure. According to the keyserver statistics, there are 848 primary ElGamal signing keys which are affected. These are a mere 0.04 percent of all primary keys on the keyservers. There are 324 vulnerable subkeys on the keyservers, too. Some of the subkeys might have never been used for signing because for some time in the past GnuPG created the encryption subkey as type 20 but didn't used it for signing because the DSA primary key was used instead. It is better to revoke such keys nevertheless. Note again that the standard configuration of GnuPG does not allow creating the vulnerable sign+encrypt ElGamal keys and that neither DSA (type 17), RSA (type 1) nor ElGamal encrypt-only keys (type 16) are affected. Thanks ====== Phong Nguyen [4] analyzed the implementation of GnuPG's cryptographic parts and found this vulnerability. He also developed actual code to mount the attack and was so kind to give me enough time to have a look at his paper and to gather a list of known type 20 keys owners. I am really sorry for this, Werner [1] To get a fresh key you might want to consult the keyservers or get it from using "finger wk@g10code.com" or "finger dd9jn@gnu.org". [2] See http://lists.gnupg.org/mailman/listinfo/gnupg-users . [3] The patent status of DSA was not clear when I started to write GnuPG back in 1997. [4] Working at the French National Center for Scientific Research and the Ecole normale superieure: http://www.di.ens.fr/~pnguyen/ . -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xavwaLeriVdUjc0RAquhAJ9crSJ2j8EbqaAnbJGoXBsgERPLaACePwcP 70laYWsyhXkzVgqL2X4ELVk= =xGWG -----END PGP SIGNATURE----- From wk at gnupg.org Thu Nov 27 09:32:55 2003 From: wk at gnupg.org (Werner Koch) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] GnuPG 1.2.3 patch to remove ElGamal signing keys Message-ID: <87he0q8b48.fsf@alberti.g10code.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 NotDashEscaped: You need GnuPG to verify this message Hi, David Shaw wrote a patch against GnuPG 1.2.3 to disable the ability to create signatures using the ElGamal sign+encrypt (type 20) keys as well as to remove the option to create such keys. This patch will go into the next release; if you feel better with those flawed features disabled, you may want to apply this patch. Thanks, Werner Index: getkey.c =================================================================== RCS file: /cvs/gnupg/gnupg/g10/getkey.c,v retrieving revision 1.78.2.20 diff -u -r1.78.2.20 getkey.c --- getkey.c 21 Jul 2003 14:55:00 -0000 1.78.2.20 +++ getkey.c 27 Nov 2003 00:32:30 -0000 @@ -1655,6 +1655,11 @@ if ( x ) /* mask it down to the actual allowed usage */ key_usage &= x; } + + /* Type 20 Elgamal keys are not usable. */ + if(pk->pubkey_algo==PUBKEY_ALGO_ELGAMAL) + key_usage=0; + pk->pubkey_usage = key_usage; if ( !key_expire_seen ) { @@ -1869,6 +1874,13 @@ if ( x ) /* mask it down to the actual allowed usage */ key_usage &= x; } + + /* Type 20 Elgamal subkeys or any subkey on a type 20 primary are + not usable. */ + if(mainpk->pubkey_algo==PUBKEY_ALGO_ELGAMAL + || subpk->pubkey_algo==PUBKEY_ALGO_ELGAMAL) + key_usage=0; + subpk->pubkey_usage = key_usage; p = parse_sig_subpkt (sig->hashed, SIGSUBPKT_KEY_EXPIRE, NULL); Index: keygen.c =================================================================== RCS file: /cvs/gnupg/gnupg/g10/keygen.c,v retrieving revision 1.90.2.11 diff -u -r1.90.2.11 keygen.c --- keygen.c 16 Jul 2003 03:09:15 -0000 1.90.2.11 +++ keygen.c 27 Nov 2003 00:32:31 -0000 @@ -958,8 +958,6 @@ tty_printf( _(" (%d) DSA (sign only)\n"), 2 ); if( addmode ) tty_printf( _(" (%d) ElGamal (encrypt only)\n"), 3 ); - if (opt.expert) - tty_printf( _(" (%d) ElGamal (sign and encrypt)\n"), 4 ); tty_printf( _(" (%d) RSA (sign only)\n"), 5 ); if (addmode) tty_printf( _(" (%d) RSA (encrypt only)\n"), 6 ); @@ -989,21 +987,6 @@ algo = PUBKEY_ALGO_RSA; *r_usage = PUBKEY_USAGE_SIG; break; - } - else if( algo == 4 && opt.expert) - { - tty_printf(_( -"The use of this algorithm is only supported by GnuPG. You will not be\n" -"able to use this key to communicate with PGP users. This algorithm is also\n" -"very slow, and may not be as secure as the other choices.\n")); - - if( cpr_get_answer_is_yes("keygen.algo.elg_se", - _("Create anyway? "))) - { - algo = PUBKEY_ALGO_ELGAMAL; - *r_usage = PUBKEY_USAGE_ENC | PUBKEY_USAGE_SIG; - break; - } } else if( algo == 3 && addmode ) { algo = PUBKEY_ALGO_ELGAMAL_E; -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/xa20aLeriVdUjc0RAvXcAKCIxQR0JbaxfX/EFpI4NLcb4vUI2ACZAQTx zfX4QUrn7HnluPP4Pfoofdk= =OtPO -----END PGP SIGNATURE----- From dshaw at jabberwocky.com Thu Nov 27 21:05:30 2003 From: dshaw at jabberwocky.com (David Shaw) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] GnuPG 1.3.4 released (development) Message-ID: <20031127200530.GI28380@jabberwocky.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello! The latest release from the development branch of GnuPG is ready for public consumption. This is a branch to create what will eventually become GnuPG 1.4. It will change with greater frequency than the 1.2.x "stable" branch, which will mainly be updated for bug fix reasons. The more GnuPG-familiar user is encouraged try this release (and the ones that will follow in the 1.3.x branch), and report back any problems to gnupg-devel@gnupg.org. In return, you get the latest code with the latest features. This release contains code to address the recently discovered Elgamal sign+encrypt problem discussed in: http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html Note that this change prevents generating any new Elgamal sign+encrypt keys, and prevents generating any new Elgamal signatures or encrypting to Elgamal sign+encrypt keys. This also means that this version of GnuPG cannot be used to revoke an existing Elgamal sign+encrypt primary key (as the revocation involves issuing a signature). It can still be used to revoke an Elgamal sign+encrypt subkey with a non-Elgamal primary key. If you still have a primary Elgamal key you want to revoke, you will need to do it with an earlier version of GnuPG. As always, note that while this code is stable enough for many uses, it is still the development branch. Mission-critical applications should always use the 1.2.x stable branch. The files are available from: ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.4.tar.gz (1861k) ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.4.tar.gz.sig ftp://ftp.gnupg.org/gcrypt/alpha/gnupg/gnupg-1.3.3-1.3.4.diff.gz (242k) MD5 checksums for the files are: 3e2722be17f9ff3979c95b5fb1371818 gnupg-1.3.4.tar.gz 907cd4bbaf03d6713e697310613612e9 gnupg-1.3.3-1.3.4.diff.gz Noteworthy changes in version 1.3.4 (2003-11-27) - ------------------------------------------------ * Added support for BZIP2 compression. This should be considered experimental, and is only available if the libbzip2 library is installed. * Added the ability to handle 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. * The config file search has been enhanced to try for less specific filename matches before giving up. For example, version 1.3.4 will try for gpg.conf-1.3.4, gpg.conf-1.3, and gpg.conf-1 before falling back to the regular gpg.conf file. * Fixed a format string bug in the HKP keyserver handler. * Support for Elgamal sign+encrypt keys has been removed. Old signatures may still be verified, and existing encrypted messages may still be decrypted, but no new signatures may be issued by, and no new messages will be encrypted to, these keys. The GnuPG team (David, Stefan, Timo and Werner) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.3.4-cvs (GNU/Linux) Comment: Key available at http://www.jabberwocky.com/david/keys.asc iHEEARECADEFAj/GWQoqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk L2tleXMuYXNjAAoJEOJmXIdJ4cvJAEgAoJUJdMeIQUNLPwDXZn1jzGCGuscxAJ9c I3Ms0ID5yY8ArCXj/C6I6WXbTA== =OOeA -----END PGP SIGNATURE----- From wk at gnupg.org Wed Dec 24 13:50:17 2003 From: wk at gnupg.org (Werner Koch) Date: Wed Feb 23 12:43:35 2005 Subject: [Announce] GnuPG 1.2.4 released Message-ID: <87ad5il6ra.fsf@alberti.g10code.de> Hello! We are pleased to announce the availability of a new stable GnuPG release: Version 1.2.4 The GNU Privacy Guard (GnuPG) is GNU's tool for secure communication and data storage. It is a complete and free replacement of PGP and can be used to encrypt data and to create digital signatures. It includes an advanced key management facility and is compliant with the proposed OpenPGP Internet standard as described in RFC2440. This is mainly a bug fix release; for details see the "What's New" section below. Getting the Software ==================== GnuPG 1.2.4 can be downloaded from one of the GnuPG mirror sites or direct from ftp://ftp.gnupg.org/gcrypt . The list of mirrors can be found at http://www.gnupg.org/mirrors.html . Note, that GnuPG is not available at ftp.gnu.org. On the mirrors you should find the follwing files in the *gnupg* directory: gnupg-1.2.4.tar.bz2 (2321k) gnupg-1.2.4.tar.bz2.sig GnuPG source compressed using BZIP2 and OpenPGP signature. gnupg-1.2.4.tar.gz (3370k) gnupg-1.2.4.tar.gz.sig GnuPG source compressed using GZIP and OpenPGP signature. gnupg-1.2.3-1.2.4.diff.gz (859k) A patch file to upgrade a 1.2.3 GnuPG source. This file is signed; you have to use GnuPG > 0.9.5 to verify the signature. GnuPG has a feature to allow clear signed patch files which can still be processed by the patch utility. Select one of them. To shorten the download time, you probably want to get the BZIP2 compressed file. Please try another mirror if exceptional your mirror is not yet up to date. In the *binary* directory, you should find these files: gnupg-w32cli-1.2.4.zip (1405k) gnupg-w32cli-1.2.4.zip.sig GnuPG compiled for Microsoft Windows and OpenPGP signature. Note that this is a command line version and comes without a graphical installer tool. You have to use an UNZIP utility to extract the files and install them manually. The included file README.W32 has further instructions. Checking the Integrity ====================== In order to check that the version of GnuPG which you are going to install is an original and unmodified one, you can do it in one of the following ways: * If you already have a trusted version of GnuPG installed, you can simply check the supplied signature. For example to check the signature of the file gnupg-1.2.4.tar.bz2 you would use this command: gpg --verify gnupg-1.2.4.tar.bz2.sig This checks whether the signature file matches the source file. You should see a message indicating that the signature is good and made by that signing key. Make sure that you have the right key, either by checking the fingerprint of that key with other sources or by checking that the key has been signed by a trustworthy other key. Note, that you can retrieve the signing key using "finger wk 'at' g10code.com" or "dd9jn 'at' gnu.org" or using the keyservers. I just prolonged the expiration date; thus you need a fresh copy of that key RSN. Never use a GnuPG version you just downloaded to check the integrity of the source - use an existing GnuPG installation! * If you are not able to use an old version of GnuPG, you have to verify the MD5 checksum. Assuming you downloaded the file gnupg-1.2.4.tar.bz2, you would run the md5sum command like this: md5sum gnupg-1.2.4.tar.bz2 and check that the output matches the first line from the following list: 16d0b575812060328f8e677b7f0047cc gnupg-1.2.4.tar.bz2 adfab529010ba55533c8e538c0b042a2 gnupg-1.2.4.tar.gz 8186b9a52bd65e87ce65824cf62d3916 gnupg-1.2.3-1.2.4.diff.gz bb568fe26abbe045d91f95ae0324eab2 gnupg-w32cli-1.2.4.zip Upgrade Information =================== If you are upgrading from a version prior to 1.0.7, you should run the script tools/convert-from-106 once. Please note also that due to a bug in versions prior to 1.0.6 it may not be possible to downgrade to such versions unless you apply the patch http://www.gnupg.org/developer/gpg-woody-fix.txt . If you have any problems, please see the FAQ and the mailing list archive at http://lists.gnupg.org. Please direct questions to the gnupg-users@gnupg.org mailing list. What's New =========== Here is a list of major user visible changes since 1.2.2: * Added read-only support for BZIP2 compression. This should be considered experimental, and is only available if the libbzip2 library is installed. * Added the ability to handle messages that can be decrypted with either a passphrase or a secret key. * Most support for Elgamal sign+encrypt keys has been removed. Old signatures may still be verified, and existing encrypted messages may still be decrypted, but no new signatures may be issued by, and no new messages will be encrypted to, these keys. Elgamal sign+encrypt keys are not part of the web of trust. The only new message that can be generated by an Elgamal sign+encrypt key is a key revocation. Note that in a future version of GnuPG (currently planned for 1.4), all support for Elgamal sign+encrypt keys will be removed, so take this opportunity to revoke old keys now. * A Russian translation is included again as well as a new Bela-Russian translation. Internationalization ==================== GnuPG comes with support for 27 languages: American English Indonesian (id) Bela-Russian (be) Italian (it) Catalan (ca) Japanese (ja) Czech (cs) Polish (pl)[*] Danish (da)[*] Brazilian Portuguese (pt_BR)[*] Dutch (nl)[*] Portuguese (pt)[*] Esperanto (eo)[*] Romanian (ro) Estonian (et) Russian (ru) Finnish (fi)[*] Slovak (sk) French (fr) Spanish (es) Galician (gl) Swedish (sv)[*] German (de) Traditional Chinese (zh_TW)[*] Greek (el) Turkish (tr) Hungarian (hu) Languages marked with [*] were not updated for this release and you may notice untranslated messages. Many thanks to the translators for their ongoing support of GnuPG. Future Directions ================= GnuPG 1.2.x is the current stable branch and won't undergo any serious changes. We will just fix bugs and add compatibility fixes as required. GnuPG 1.3.x is the version were we do most new stuff and it will lead to the next stable version 1.4 not too far away. GnuPG 1.9.x is brand new and flagged as experimental. This version merged the code from the Aegypten project and thus it includes the gpg-agent, a smartcard daemon and gpg's S/MIME cousin gpgsm. The design is different to the previous versions and we won't support any ancient systems - thus POSIX compatibility will be an absolute requirement for supported platforms. 1.9 is based on the current 1.3 code and has been released to have software ready to play with the forthcoming OpenPGP smartcard. The OpenPGP smartcard is a specification of an ISO 7816 based application to generate or import keys into a smartcard and provide all functionality to use this card with OpenPGP. The specification features 3 1024 bit RSA keys (signing, decryption and authentication) as well as utility data objects to make integration easy. GnuPG 1.3.x supports this card; see http://g10code.com/p-card.html . Please consider to buy maintenance points to help with the development; see http://g10code.com/products.html#maintpoints . Merry Christmas and happy New Year, The GnuPG team (David, Stefan, Timo and Werner) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 188 bytes Desc: not available Url : /pipermail/attachments/20031224/bc6f01f2/attachment.pgp