[ Date Index ][
Thread Index ]
[ <= Previous by date / thread ] [ Next by date / thread => ]
On Friday 28 Nov 2003 8:10 pm, Simon Waters wrote: > For those that don't subscribe to gnu.announce but do use GnuPG, this is > a heads up on Werner's latest post. A severe problem with ElGamal sign+encrypt keys has been found. This leads to a full compromise of the private key. Fortunately those keys are not in wide use and only creatable using special options. Please see the advisory for details. http://lists.gnupg.org/pipermail/gnupg-announce/2003q4/000276.html (Brief explanation) Werner's post on gnupg-users relates to a vulnerability on a key creation method that is already deprecated in GnuPG, requires unusual options to be used on the command line to make available and generates several warnings during creation about the lack of security of the method. No-one using a default GnuPG key needs to be concerned. There is no-one on the DCLUG keyring who is affected by the vulnerability. There is also no-one in my usual contact list who is affected. According to the keyserver statistics, there are 848 primary vulnerable 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. > Will our resident expert(s?) expand on the significance of revoking > subkeys, as I assume there is some re-sign-ing (there must be a better subkeys are only self-signed. Only user ID's accept signatures by other keyholders. $ gpg --list-keys 28bcb3e3 pub 1024D/28BCB3E3 2002-01-27 Neil Williams (CodeHelp) uid N Williams (CodeHelp) uid Neil Williams (Linux User Group) uid Neil Williams (general) uid Neil Williams (Devon and Cornwall LUG) sub 1024g/AD3CB326 2002-01-27 The subkey AD3CB326 can only be signed by me. (This also illustrates how to satisfy yourself of your own security: My key is not vulnerable because the public key is 1024D and the subkey is 1024g - like most default GnuPG keys. The vulnerable keys use a G instead of D or g (or a few other types, none of which are vulnerable). In this case, the capital G is imperative - a lower case g is secure, ONLY an upper case G is vulnerable - there are no exceptions.) Revoking an affected subkey doesn't affect the web of trust or signatures on the main key. Some users have used the vulnerable method for their main key and have to revoke the entire key. Others who used only a subkey using this method can revoke the bad subkey and add a new subkey using one of the default methods for full security. Forthcoming GnuPG versions will remove the ability to create such keys and the ability create vulnerable signatures based on such keys. -- Neil Williams ============= http://www.codehelp.co.uk/ http://www.dclug.org.uk/ http://www.isbn.org.uk/ http://sourceforge.net/projects/isbnsearch/ http://www.biglumber.com/x/web?qs=0x8801094A28BCB3E3
Attachment:
pgp00008.pgp
Description: signature