[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] [Fwd: [Fwd: Serious bug in PGP - versions 5 and 6]]
Ben Laurie wrote:
> 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: firstname.lastname@example.org
> To: email@example.com
> 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
> 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.
> > 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." firstname.lastname@example.org