From prz@pgp.com Fri Oct 20 23:17:15 2000
Date: Fri, 20 Oct 2000 12:29:37 -0700
From: Philip Zimmermann 
To: Ralf Senderek 
Cc: Stale Schumacher Ytteborg 
Subject: Updated remarks from Zimmermann on ADK bug

Philip Zimmermann's personal response to the ADK bug,
updated 20 October 2000.

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 24 August, we found out that we had a security related
bug in PGP, in the implementation of the Additional Decryption Key
(ADK) feature.  A German researcher, Ralf Senderek, had already
published news of this bug on a web site.  We mobilized quickly and
released a fixed version of PGP within about 18 hours of hearing the
news.  The fix for the commercial version of PGP is available from
http://www.pgp.com, and the fixed freeware PGP (version 6.5.8) is
available from the MIT web site at
http://web.mit.edu/network/pgp.html, or from http://www.pgpi.org.
Of course, our subsequent releases of PGP (like 7.0) are also fixed.

Some of the postings on the Internet about this subject have
portrayed this bug as a back door in PGP.  Let me assure you, it is
nothing of the sort.  It is a bug (and we have now fixed it).  An
especially embarrassing bug, because it is in a feature that some
people have objected to even when everyone thought it was working
correctly.

The ADK feature was designed in 1997 to be a kinder, gentler
alternative to key escrow for companies to use for employee's keys. 
I felt that key escrow was an especially bad idea, and came up with
this alternative:  Imagine that you published your public key with a
little yellow Post-it note (digitally signed by you) attached to it,
asking users who want to encrypt with your public key to encrypt the
message with another key as well.  That means the note asks users to
encrypt the message with two keys instead of one -- the intended
recipient's key, and an additional key chosen by the recipient,
identified on the little Post-it note.  It is a request from the
recipient that the sender of a message may choose to comply with, or
choose to ignore.  The sender is free to encrypt the message with
one key, or both keys.  If he chooses to comply with the recipient's
wishes and use the ADK, either the intended recipient or the ADK may
decrypt the message.  This satisfied a major requirement from our
corporate customers for a mechanism of handling what happens when an
employee is not available to decrypt the file, perhaps because he's
on vacation, or died in a plane crash, or simply forgot his pass
phrase.  It is so much better than key escrow because it requires the
consent of both the sender and receiver to use the feature.  It is
highly visible to the sender, and asks his consent before proceeding
with the encryption.  

We could not sell PGP without this feature.  Most freeware users
didn't need this feature, so we did not make the freeware version of
PGP capable of generating ADKs on their keys.  You have to buy the
commercial version to generate keys with proper ADK packets attached
to them.  Since the freeware users don't pay the salaries of our
engineers, and the commercial users do, we had to add this feature
to PGP to meet an absolute requirement of most of our paying
customers.  It seems the most militant critics of the ADK feature are
also the ones who don't want to pay for PGP.  Somebody has to pay the
engineers so that we can keep developing PGP and give it away for
free to these critics.

The recipient has to make a digital signature on the little yellow
Post-it note, giving his consent to having an ADK associated with his
key.  And therein lies the bug.  The bug in PGP versions 5.5 through
6.5.3 is that PGP does not always properly check to see if the ADK is
signed before using it, if the little Post-it note that references
the ADK is improperly formatted in a particular way.  This means
someone could attach an unauthorized ADK to your key, and possibly
fool an inattentive message sender into using it.  It would not be an
easy scam to pull off, because chances are, the sender does not have
the bogus ADK on his keyring, and even if he goes through the extra
trouble to get it from a server, the bogus ADK is probably not going
to be signed by a Certificate Authority trusted by the sender.  In
which case, PGP will display the bad ADK validity status to him
before he can use that ADK to encrypt the message.  This is a daring
attack, an attack that has a very high probability of being detected.
Then, even if all those problems are somehow overcome, the attacker
still has to intercept the encrypted email on its way to the intended
recipient.  Intelligence agencies are good at intercepting email
traffic, but they would never be foolish enough to try a daring
attack.  That might be why we found absolutely no bogus ADK packets
when we scanned all the public keys on the public key servers after
the bug was reported, even after nearly three years of deployment of
this bug.  If this were a back door, it would be a particularly
stupid design for a back door.

Anyway, did I mention that we fixed the bug?  We also fixed it on the
key servers so that the key servers would reject (and delete) bogus
ADKs before anyone had a chance to use them, even if they did not yet
have the new fixed version of PGP.  The fixed version of PGP deletes
bogus ADKs wherever it finds them.  It does not simply avoid using
the bogus ADKs, it actually deletes them from the key.  They are
gone.  Ironically, our most cynical critics objected to this way of
fixing the bug, accusing us of "covering up" the bogus ADKs because
they could not see them anymore (maybe they did not realize the bogus
ADKs were actually gone).  Sigh.  Some people are impossible to
please.

We also made a change to the freeware version of PGP 7.0 to make it
impossible for the user to turn off warnings about the presence of an
ADK on a key before using it.  If you intend to use ADKs a lot and
want to be able to turn off these warnings via the preferences panel,
you must buy the commercial version of PGP.  In both the commercial
and freeware PGP 7.0, we also made the warnings to the user far more
explicit when encrypting to a key with the ADK feature.

Senderek's report suggested that the same bug also affects other
kinds of attributes you attach to your key, including the designated
revoker feature in PGP.  We fixed these problems at the same time, in
the same way.  Although these variations on the bug were less serious
than the ADK bug (and did not involve such a controversial feature),
they would have allowed unauthorized designated revokers to be added
to your key, which could potentially open the door to a denial of
service attack by allowing someone to revoke your key.  In fact,
while we were examining the source code to fix the designated revoker
feature, we discovered another bug relating to designated revokers
and fixed that too.  That bug allowed invalid designated revoker
signatures to be accepted under some circumstances.  This in no way
could have hurt the security of PGP messages, but could have allowed
valid keys to appear revoked.  We also fixed the key servers to
filter out all of these problems for everyone's keys.

When we added the ADK feature in 1997, many critics charged that this
would pave the way for government law enforcement or intelligence
agencies to exploit the ADK feature to spy on ordinary citizens.  In
fact, this has not happened.  After many years of struggle, we have
won the crypto debate in the US (and France, and a growing list of
other countries in Europe), and the US export controls were relaxed
completely in January 2000.  After nearly three years of deployment,
the ADK feature has had absolutely zero impact on the state of
government surveillance in the US, and around the world.  The
predictions were wrong.  At the same time, the commercial acceptance
of PGP (in part because of the addition of the ADK feature) has
propagated PGP more widely in the politically powerful computer
industry, which I suspect has in some way contributed to pressure on
the government to relax the export controls in this election year.

One annoying thing I've seen in some of these press reports on the
web is that adding this ADK feature had something to do with the Key
Recovery Alliance (KRA), an industry group formed in the 1990s to put
key recovery features in crypto products, mostly to allow those
products to get export licenses from the US government.  Let me
assure you all that the KRA has nothing to do with us adding this
feature to PGP.  I had this ADK feature added to PGP in late 1997,
before Network Associates acquired PGP Inc.  We added it because it
was a good feature to solve specific data recovery problems that
corporations had, problems I have described above.  It had nothing to
do with export licenses.  We avoided the export controls by
publishing PGP source code in printed books and legally exporting the
books (which were not subject to export controls) to Europe, where
they were scanned in via OCR and compiled back into working software
again and sold on CDROMs all over the world.  A neat trick, don't you
think?  It worked beautifully, and there was no need for us to
compromise PGP's cryptographic integrity to allow it to be exported. 
Anyway, later Network Associates acquired PGP Inc, and I made them
drop out of the KRA as soon as they did.  A few months later, NAI
acquired another company (TIS), which was a member of the KRA, and
thereby became a member again by default.  Their membership was up
for renewal, and I asked them not to renew, and they again complied
with my request.  Today it appears the KRA no longer exists, now that
the export controls are gone.

No one made any deals with the government.  There is no conspiracy
here.  There are still no back doors in PGP.  We still publish the
PGP source code for peer review, because we want people to help us
find the bugs.  Most other software companies don't do that.  Their
software is as big and complex as ours, so they probably have as many
(if not more) bugs, but you don't hear about them as much because the
source code is not published for peer review.

PGP started out as a human rights project, and today is used by every
human rights organization in the world.  Our engineers stay with the
PGP team because they feel that they are working on something
important for the world.  It's a thankless job for most of them,
especially with all this criticism from conspiracy theorists who
imagine we've sold out to the government.  Why do people have to
assume the worst motives?  If NAI tried to put a back door in PGP,
all the engineers on the PGP team would quit in a highly visible
protest, and I would be talking to the press about it.  There is no
way that I would let this happen, and NAI has shown no interest in
putting a back door in PGP.


Philip Zimmermann
29 August 2000 (updated 20 October 2000)
prz@pgp.com
http://www.pgp.com/phil

This note may be widely circulated.

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0

iQA/AwUBOfCb5mPLaR3669X8EQJE6ACeMmGz9FvZi72VNU3XeZCa/MntiD0AoP5z
ih2AwBgKXqKzIsSROGNPYtiF
=yq/N
-----END PGP SIGNATURE-----