FW: Serious bug in PGP - versions 5 and 6

[Simpson, Sam]

Sounds serious to me....Any comments from NAI staff?



Regards,

Sam Simpson
http://www.scramdisk.clara.net/

> -----Original Message-----
> From: Ross Anderson [mailto:Ross.Anderson@cl.cam.ac.uk] 
> Sent: 24 August 2000 07:57
> To: ukcrypto@maillist.ox.ac.uk
> Subject: Serious bug in PGP - versions 5 and 6 
> 
> 
> Ralf Senderek has found a horrendous bug in PGP versions 5 and 6.
> It's of scientific interest because it spectacularly confirms a
> prediction made by a number of us in the paper on `The Risks of Key
> Recovery, Key Escrow, and Trusted Third-Party Encryption'
> <http://www.cdt.org/crypto/risks98/> that key escrow would make it
> much more difficult than people thought to build secure systems.
> 
> He's written a paper on his work and it's at
> 
> 	http://senderek.de/security/key-experiments.html
> 
> Since NAI joined the Key Recovery Alliance, PGP has supported
> "Additional Decryption Keys" which can be added to a public key.  The
> sender will then encrypt the session key to these as well as to your
> main public key. The bug is that some versions of PGP respond to ADK
> subpackets in the non-signed part of the public key data structure.
> The effect is that GCHQ can create a tampered version of your PGP
> public key containing a public key whose corresponding private key is
> also known to themselves, and circulate it. People who encrypt traffic
> to you will encrypt it to them too.
> 
> The problem won't go away until all vulnerable versions of PGP are
> retired, since it's the sender who is responsible for encrypting to
> the ADKs, not the recipient.
> 
> In the meantime there might be a nasty denial-of-service attack in
> which bad guys upload tampered versions of everybody's public keys to
> all the public keyrings.
> 
> Ross
> 
> 
> > PS: my student Steve Early has trawled the PGP-6.5.1i-beta2 source
> > code and found the bug:
> > 
> > In file libs/pgpcdk/priv/keys/keys/pgpRngPub.c, I see two functions:
> > one called ringKeyFindSubpacket(), which finds a subpacket from a
> > self-signature packet, and ringKeyAdditionalRecipientRequestKey(),
> > which uses ringKeyFindSubpacket() to search for ADK subpackets.
> > 
> > ringKeyFindSubpacket() is declared as follows:
> > 
> > PGPByte const *
> > ringKeyFindSubpacket (RingObject *obj, RingSet const *set,
> >         int subpacktype, unsigned nth,
> >         PGPSize *plen, int *pcritical, int *phashed, 
> PGPUInt32 *pcreation,
> >         unsigned *pmatches, PGPError *error);
> > 
> > In particular, the "phashed" parameter is used to return whether the
> > subpacket was in the hashed region. Now, looking at the call in
> > ringKeyAdditionalRecipientRequestKey() I see this:
> > 
> >         krpdata = ringKeyFindSubpacket (obj, set,
> >                 SIGSUB_KEY_ADDITIONAL_RECIPIENT_REQUEST, 
> nth, &krdatalen,
> >                 &critical, NULL, NULL, &matches, error);
> > 
> > ...the "phashed" value isn't checked (or even asked for)!
> > 
> > 
> > Fixing the bug, and generating BIG WARNINGS when ADKs are 
> found in the
> > non-hashed area, should be trivial.
> 
> 

-- 
Archive is at http://lists.gnupg.org - Unsubscribe by sending mail
with a subject of  "unsubscribe"  to gnupg-users-request@gnupg.org