disable elgamal keys.

4 files changed, 472 insertions, 2 deletions

diff --git a/app-crypt/gnupg/Manifest b/app-crypt/gnupg/Manifest
index 8bcdbb3d5bb8..dd3c203a0149 100644
--- a/app-crypt/gnupg/Manifest
+++ b/app-crypt/gnupg/Manifest
@@ -1,7 +1,7 @@
 MD5 b1b8b51a3ba07896162db22ca158d07d gnupg-1.2.3-r2.ebuild 1638
-MD5 19f5157b5a29859e09f4d5a3e0cefb38 gnupg-1.2.3-r4.ebuild 2982
+MD5 0fba217c4581fac9583ee1aefdf301ae gnupg-1.2.3-r4.ebuild 3052
 MD5 6f0148d960aaa3208aa4c74705805277 gnupg-1.2.3-r3.ebuild 2656
-MD5 7b261525697b0f43c2c8470aa55d7f65 ChangeLog 5931
+MD5 3e68fd3de3d757f4ffc40b766a7f40a7 ChangeLog 6178
 MD5 5ffa87354a03beae320d15a7be997529 gnupg-1.2.2-r1.ebuild 1629
 MD5 773ecd19392b8f793d7626c9814e1e0b files/digest-gnupg-1.2.2-r1 65
 MD5 eecb1b58574b61ddac7c3d12b0143b7d files/digest-gnupg-1.2.3-r2 65
diff --git a/app-crypt/gnupg/files/digest-gnupg-1.2.3-r4 b/app-crypt/gnupg/files/digest-gnupg-1.2.3-r4
new file mode 100644
index 000000000000..f63dbab6d49f
--- /dev/null
+++ b/app-crypt/gnupg/files/digest-gnupg-1.2.3-r4
@@ -0,0 +1 @@
+MD5 cdca1282d7901f9ddb52f9725b001af2 gnupg-1.2.3.tar.bz2 2294773
diff --git a/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff b/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff
new file mode 100644
index 000000000000..d0053bea601c
--- /dev/null
+++ b/app-crypt/gnupg/files/gnupg-1.2.3-disable-elgamal.diff
@@ -0,0 +1,353 @@
+From: wk@gnupg.org (Werner Koch)
+Newsgroups: mailing.unix.bugtraq
+Subject: GnuPG's ElGamal signing keys compromised
+Date: Thu, 27 Nov 2003 18:31:32 +0000 (UTC)
+Organization: NCTU CSIE FreeBSD Server
+Lines: 338
+Sender: nobody@FreeBSD.csie.NCTU.edu.tw
+Message-ID: <bq5fu4$65h$1@FreeBSD.csie.NCTU.edu.tw>
+NNTP-Posting-Host: freebsd.csie.nctu.edu.tw
+X-Trace: FreeBSD.csie.NCTU.edu.tw 1069957892 6322 140.113.17.209 (27 Nov 2003 18:31:32 GMT)
+X-Complaints-To: usenet@FreeBSD.csie.NCTU.edu.tw
+NNTP-Posting-Date: Thu, 27 Nov 2003 18:31:32 +0000 (UTC)
+
+
+
+-----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 <mallory@example.net>
+
+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 <wk@gnupg.org>
+  uid                            Werner Koch <werner.koch@guug.de>
+  uid                            Werner Koch <wk@g10code.com>
+  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 <foo.rev
+
+now export your key to a file and distribute it to the keyservers.
+
+  gpg --export -a your_keyid >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-----
+
+
+
+--=-=-=
+Content-Type: text/x-patch
+Content-Disposition: attachment; filename=elgamal.patch
+
+-----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-----
+
+--=-=-=--
+
+
diff --git a/app-crypt/gnupg/gnupg-1.2.3-r4.ebuild b/app-crypt/gnupg/gnupg-1.2.3-r4.ebuild
new file mode 100644
index 000000000000..c745f353b435
--- /dev/null
+++ b/app-crypt/gnupg/gnupg-1.2.3-r4.ebuild
@@ -0,0 +1,116 @@
+# Copyright 1999-2003 Gentoo Technologies, Inc.
+# Distributed under the terms of the GNU General Public License v2
+# $Header: /var/cvsroot/gentoo-x86/app-crypt/gnupg/gnupg-1.2.3-r4.ebuild,v 1.1 2003/11/29 22:31:11 taviso Exp $
+
+inherit eutils
+
+DESCRIPTION="The GNU Privacy Guard, a GPL pgp replacement"
+HOMEPAGE="http://www.gnupg.org/"
+SRC_URI="ftp://ftp.gnupg.org/gcrypt/gnupg/${P}.tar.bz2"
+SLOT="0"
+LICENSE="GPL-2"
+KEYWORDS="~x86 ~alpha ~sparc ~hppa ~ia64"
+IUSE="X ldap nls static caps"
+
+RDEPEND="!static? ( ldap? ( net-nds/openldap )
+		caps? ( sys-libs/libcap )
+		sys-libs/zlib )
+	X? ( x11-misc/xloadimage )
+	nls? ( sys-devel/gettext )
+	virtual/glibc
+	dev-lang/perl
+	virtual/mta"
+
+# XXX: libpcap earlier than 1.10-r3 did not provide libcap.a
+#	DEPEND="caps? ( static? ( >=sys-libs/libcap-1.10-r3 )
+#				!static? ( sys-libs/libcap ) )
+DEPEND="caps? ( sys-libs/libcap )
+	ldap? ( net-nds/openldap )
+	nls? ( sys-devel/gettext )
+	!static? ( sys-libs/zlib )
+	virtual/glibc
+	dev-lang/perl"
+
+src_unpack() {
+	unpack ${A}
+
+	# 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.
+	#
+	# http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000277.html
+	cd ${S}/g10; epatch ${FILESDIR}/${P}-disable-elgamal.diff
+}
+
+src_compile() {
+	# support for external HKP keyservers requested in #16457.
+	# gpg faq entry 3.3 reccommends using --enable-static-rnd=linux 
+	# whenever possible.
+	local myconf="--enable-external-hkp --enable-static-rnd=linux --libexecdir=/usr/lib"
+
+	if ! use nls; then
+		myconf="${myconf} --disable-nls"
+	fi
+
+	if use ldap; then
+		myconf="${myconf} --enable-ldap"
+	else
+		myconf="${myconf} --disable-ldap"
+	fi
+
+	if use X; then
+		myconf="${myconf} --enable-photo-viewers"
+	else
+		myconf="${myconf} --disable-photo-viewers"
+	fi
+
+	# `USE=static` support was requested in #29299
+	if use static; then
+		myconf="${myconf} --with-included-zlib"
+		export LDFLAGS="${LDFLAGS} -static"
+	else
+		myconf="${myconf} --without-included-zlib"
+	fi
+
+	if use caps; then
+		myconf="${myconf} --with-capabilities"
+	fi
+
+	# Still needed?
+	# Bug #6387, --enable-m-guard causes bus error on sparcs
+	if ! use sparc; then
+		myconf="${myconf} --enable-m-guard"
+	fi
+
+	econf ${myconf} || die
+	emake || die
+}
+
+src_install() {
+	einstall libexecdir="${D}/usr/lib/gnupg"
+
+	# keep the documentation in /usr/share/doc/...
+	rm -rf "${D}/usr/share/gnupg/FAQ" "${D}/usr/share/gnupg/faq.html"
+
+	dodoc ABOUT-NLS AUTHORS BUGS COPYING ChangeLog INSTALL NEWS PROJECTS \
+	README THANKS TODO VERSION doc/{FAQ,HACKING,DETAILS,ChangeLog,OpenPGP,faq.raw}
+
+	newdoc ${FILESDIR}/${P}-disable-elgamal.diff README.elgamal
+
+	docinto sgml
+	dodoc doc/*.sgml
+
+	dohtml doc/faq.html
+
+	if ! use caps; then
+		chmod u+s "${D}/usr/bin/gpg"
+	fi
+}
+
+pkg_postinst() {
+	if ! use caps; then
+		einfo "gpg is installed suid root to make use of protected memory space"
+		einfo "This is needed in order to have a secure place to store your"
+		einfo "passphrases, etc. at runtime but may make some sysadmins nervous."
+	fi
+}