SecurityTracker.com
Keep Track of the Latest Vulnerabilities
with SecurityTracker!
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 
Sign Up
Sign Up for Your FREE Weekly SecurityTracker E-mail Alert Summary
Instant Alerts
Buy our Premium Vulnerability Notification Service to receive customized, instant alerts
Affiliates
Put SecurityTracker Vulnerability Alerts on Your Web Site -- It's Free!
Partners
Become a Partner and License Our Database or Notification Service
Report a Bug
Report a vulnerability that you have found to SecurityTracker
bugs
@
securitytracker.com






Category:   Application (Security)  >   GnuPG (Gnu Privacy Guard) Vendors:   Gnupg.org
GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
SecurityTracker Alert ID:  1008319
SecurityTracker URL:  http://securitytracker.com/id/1008319
CVE Reference:   CAN-2003-0971   (Links to External Site)
Updated:  Dec 2 2003
Original Entry Date:  Nov 27 2003
Impact:   Disclosure of authentication information
Vendor Confirmed:  Yes  
Version(s): 1.0.2 and later versions
Description:   A vulnerability was reported in GnuPG in the creation of ElGamal keys for digital signature. Keys used for signing can be compromised.

It is reported that Phong Nguyen discovered a flaw that allows a remote user to determine your private key within a few seconds.

In version 1.0.2 (January 2000), the flaw was introduced when the GnuPG code was modified to improve the efficiency of encryption using ElGamal keys. A common factor was used for encrypting and signing. As a result, a remtote user with access to a target user's signature can conduct a cryptographic attack to determine the target user's private key. This flaw reportedly affects only ElGamal sign+encrypt keys (type 20) in GnuPG version 1.0.2 and later.

The vendor reports that ElGamal encrypt-only keys (type 16) are not affected. Also, the DSA keys and RSA keys are not vulnerable, according to the report.

Impact:   A remote user can determine the ElGamal private key.
Solution:   No solution was available at the time of this entry. The vendor reports that you should immediately revoke your ElGamal signing keys and should not use "ElGamal sign+encrypt keys (type 20)." The vendor indicates that you should consider all material signed or encrypted with such a key as compromised.

Future versions of GnuPG will remove the ability to create such keys and create ElGamal signatures.

Vendor URL:  www.gnupg.org/ (Links to External Site)
Cause:   State error
Underlying OS:  Linux (Any), UNIX (Any)

Message History:   This archive entry has one or more follow-up message(s) listed below.
Nov 28 2003 (Mandrake Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Mandrake has released a fix.
Dec 3 2003 (SuSE Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
SuSE has issued a fix.
Dec 9 2003 (Conectiva Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Conectiva has released a fix.
Dec 11 2003 (Red Hat Issues Fix for RH Linux) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Red Hat has released a fix for Red Hat Linux.
Dec 11 2003 (Red Hat Issues Fix for RH Enteprise Linux) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Red Hat has released a fix for Red Hat Enterprise Linux.
Dec 12 2003 (Gentoo Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Gentoo has released a fix.
Dec 18 2003 (Turbolinux Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Turbolinux has issued a fix.
Jan 27 2004 (Debian Issues Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Debian has released a fix.
Feb 14 2004 (Debian Issues Updated Fix) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Debian has released an updated fix, providing a "more correct and permanent fix" than the previous Debian fix.
Feb 17 2004 (Sun Issues Fix for Cobalt RaQ) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
Sun issues a fix for GnuPG for Cobalt RaQ.
Mar 5 2004 (SCO Issues Fix for OpenLinux) GnuPG ElGamal Signature Flaw May Disclose Type 20 ElGamal Private Keys to Remote Users
SCO has issued a fix for OpenLinux 3.1.1.



 Source Message Contents

Date:  Thu, 27 Nov 2003 09:44:30 +0100
Subject:  [Full-Disclosure] GnuPG's ElGamal signing keys compromised


--=-=-=

-----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-----

--=-=-=--

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

Copyright 2017, SecurityGlobal.net LLC