[freehaven-dev] [Fwd: [Fwd: Serious bug in PGP - versions 5 and 6]]

["Michael J. Freedman" <mfreed@zeroknowledge.com>]

Ben Laurie wrote:
> 
> --
> http://www.apache-ssl.org/ben.html
> 
> Coming to ApacheCon Europe 2000? http://apachecon.com/
> 
>   ------------------------------------------------------------------------
> 
> Subject: Serious bug in PGP - versions 5 and 6
> Date: Thu, 24 Aug 2000 08:09:07 +0100
> From: Ross Anderson <Ross.Anderson@cl.cam.ac.uk>
> Reply-To: ukcrypto@maillist.ox.ac.uk
> To: ukcrypto@maillist.ox.ac.uk
> 
> 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.

-- 
"Not all those who wander are lost."      mfreed@zeroknowledge.com