<!-- SBZ_reproduce  -->
-

Ah, thanks. The full disclosure is worth reading carefully. 
Fortunately, most users of GnuPG won't be affected at all. 
 
Those who are can solve it by revoking their keys. 
Thus the important thing about this is the advisory, telling people what 
happened, how to find out whether they are affected and how to revoke their 
key if they are. 
 
So, should I submit packages with the patch applied, disabling the use of 
ElGamal Sign+Encrypt keys? Is it time-critical? 
 

I agree that this is mostly an education thing. It's even likely 
that forcing people to update now makes it impossible for them to  
revoke their ElGamal signing keys (the patch sets the key usage to 
NUL, so you can't sign anything with it, not even the revocation 
certificate). 
 
I suggest the best approach now is to publish an advisory with a 
brief excerpt from Werner's message, and tell people to trash their 
ElGamal signing keys. 
 
Maybe we should ask Werner for permission to copy the relevant portion 
of his advisory (How do I find out if I have an ElGamal key?) 

Or you could copy the description from the heise newsticker which is not so 
bad either. Either one should be OK. 
 
The thing about the patch may be disallowing to create a revocation cert is 
indeed something I did not think about. It would be a bad thing ... 
 
There's also a fmt str bug in the 1.2.x HKP code, so I submitted updated 
packages for 8.2, 9.0 and SLEC (aka SLD) last night. And I did include the 
ElGamal deactivation patch as well. It might be wise to check whether it 
really has this nasty side effect. 
 

With old gpg: 
$ gpg --expert --gen-key 
4 
[...] 
pub  1024G/9BED2BDB 2003-11-28 TEST ElGamal Key (Test for #33369) 
<testkey@elgamal.key> 
     Key fingerprint = EF63 F8E3 9113 0511 7A02  7824 73E8 6350 9BED 2BDB 
 
$ gpg --gen-revoke 9BED2BDB 
gpg: WARNING: using insecure memory! 
gpg: please see http://www.gnupg.org/faq.html for more information 
 
sec  1024G/9BED2BDB 2003-11-28   TEST ElGamal Key (Test for #33369) 
<testkey@elgamal.key> 
 
Create a revocation certificate for this key? y 
Please select the reason for the revocation:    
  0 = No reason specified 
  1 = Key has been compromised 
  2 = Key is superseded 
  3 = Key is no longer used 
  Q = Cancel 
(Probably you want to select 1 here) 
Your decision? 1 
[...] 
-----BEGIN PGP PUBLIC KEY BLOCK----- 
Version: GnuPG v1.2.2 (GNU/Linux) 
Comment: A revocation certificate should follow 
 
iQEiBCAUAgAKBQI/x1nEAx0CMAAKCRBz6GNQm+0r26M6A/9Fx+beGq1fz11pVImR 
[...] 
=6QoQ 
-----END PGP PUBLIC KEY BLOCK----- 
 
New GnuPG: 
garloff@tpkurt:~ [0]$ rpm -q --changelog gpg | head 
* Thu Nov 27 2003 - garloff@suse.de 
 
- Fix format string bug in HKP keyserver module. 
- Disable possibility to create ElGamal type 20 (sign+encrypt) keys 
  as they are vulnerable to attacks. [#33369] 
 
garloff@tpkurt:~ [0]$ gpg --gen-revoke 9BED2BDB 
[...] 
-----BEGIN PGP PUBLIC KEY BLOCK----- 
Version: GnuPG v1.2.2 (GNU/Linux) 
Comment: A revocation certificate should follow 
 
iQEhBCAUAgAJBQI/x13ZAh0CAAoJEHPoY1Cb7SvbtWsD/3awcNUAPIA6RWkgLovX 
[...] 
=qwFg 
-----END PGP PUBLIC KEY BLOCK----- 
garloff@tpkurt:~ [2]$ gpg --expert --gen-key 
[...] 
Please select what kind of key you want: 
   (1) DSA and ElGamal (default) 
   (2) DSA (sign only) 
   (5) RSA (sign only) 
   (7) RSA (sign and encrypt) 
Your selection? 4 
Invalid selection. 
 
=> Everything is OK. You can still create revocation certificates. 
 

packages and advisory released. 

CVE-2003-0971 - elgamal
CVE-2003-0978 - format string problem in hkp

CVE-2003-0978: CVSS v2 Base Score: 7.5 (AV:N/AC:L/Au:N/C:P/I:P/A:P)