1997-10-23 - Re: PGP Employee on MKR

Header Data

From: Anonymous <nobody@REPLAY.COM>
To: fight-censorship@vorlon.mit.edu
Message Hash: c254549d1745bd2de8358583a68d96882c3f9c7e5d604a9bda9aa6f9ba8515f7
Message ID: <199710231945.VAA05198@basement.replay.com>
Reply To: N/A
UTC Datetime: 1997-10-23 20:09:23 UTC
Raw Date: Fri, 24 Oct 1997 04:09:23 +0800

Raw message

From: Anonymous <nobody@REPLAY.COM>
Date: Fri, 24 Oct 1997 04:09:23 +0800
To: fight-censorship@vorlon.mit.edu
Subject: Re: PGP Employee on MKR
Message-ID: <199710231945.VAA05198@basement.replay.com>
MIME-Version: 1.0
Content-Type: text/plain



> FORCING ENCRYPTION TO MULTIPLE KEYS FOR ONE RECIPIENT IS ONE STEP 
> AWAY FROM GAK. FORCING ENCRYPTION TO MULTIPLE KEYS FOR ONE RECIPIENT 
> IS ONE STEP AWAY FROM GAK! FORCING ENCRYPTION TO MULTIPLE KEYS FOR 
> ONE RECIPIENT IS ONE STEP AWAY FROM GAK!! FORCING ENCRYPTION TO 
> MULTIPLE KEYS FOR ONE RECIPIENT IS ONE STEP AWAY FROM GAK!! 
> !!!*FORCING ENCRYPTION TO MULTIPLE KEYS FOR ONE RECIPIENT IS ONE 
> STEP AWAY FROM GAK*!!!

Mark, just remove the self signature on the user key.  The message
recovery key packet goes away!  That's all you have to do.  Is that
so tough?  This big threat, the dangerous CMR key, turns out to take
two seconds of user actions to be destroyed.  Something this easy to
turn off will never be good enough for GAK.

People say, "Oh, but then the government will make everybody run the
policy enforcer and reject any mail not encryped to the government."

First, if they were going to do this, they could do it with old versions
of PGP too.  Multiple recipients have been around practically forever.

Second, it's a ridiculous idea which ignores how email works.  More and
more people are running systems at home which could send and receive
SMTP mail.  The trend is towards home servers which support the multiple
home computers people will have in the next decade.  There's no way to
make those people run filters!

People say, "Oh, but they'll make it illegal to receive mail at home
without going through an ISP."  I'm serious, this has actually been
suggested on this list.  It has to be suggested, because it's the only
way this incredibly stupid scenario could be made to work.  I can only
assume that people are blinded by emotions or they wouldn't suggest such
a bizarre idea.

Making it illegal to implement probably the most widely used internet
protocol package (email) would be a totally unprecedented, invasive,
unjustifiable and unenforcable intervention by government.  If the only
way the government can enforce GAK is by making it illegal for people to
receive email through paths which don't pass through government filters
we can all rest easy, because it will never happen.

Even for the cases where filtering is done (like businesses), there are
easy countermeasures, described by no other than Jon Callas, PGP's chief
scientist!  Why would he say this if there were a massive conspiracy to
enable GAK?  He's also the one who explained the point above about the
self signature.  He has suggested two other easy workarounds:

Modify the PGP 5.0 source to put a fake recipient block on it.  How many
companies release their source so that you could do this?

Or superencrypt to the real end user, like you suggested in your scheme.
Why is this OK as a privacy workaround for your idea but it doesn't
count for PGP?

Then people say, "Oh, but PGP shouldn't have written the SMTP filter
anyway (or at least they shouldn't have put that one policy in) because
it would make it easier for the government to make everybody use it."

Ignoring all the considerations above about what a stupid idea this is,
the fact is that a simple filter like this is incredibly easy to write.
I'm sure a skilled Perl hacker like Adam Back could put together something
to check that a PGP message is encrypted to a desired key in a few hours.
There are already Perl scripts out there to help parse PGP messages.  You
just have to look at the recipients and compare with the key you want to
see.

The existence of such a filter is totally insignificant in the big
picture.  If we are ever forced into a GAK system and filtering turns
out to be a part of the picture, it will be trivial for such filters to
be created.  PGP's SMTP product will not make any difference one way or
the other.

The fact is, nobody has come up with a scenario where PGP's CMR feature
can be turned into GAK in any practical way.  They have to assume that all
kinds of changes and additions are made - inability to remove CMR keys,
forcing everyone to run SMTP filters, making it illegal to receive email
at home, preventing people from implementing clients with workarounds,
changing the technology to make it harder to implement workarounds
using binding cryptography.  Any system can be turned into GAK if you're
allowed to postulate these kinds of changes.  And the fact is that every
GAK system so far designed can be trivially defeated.

The big GAK danger has always been that the encryption manufacturers
would release GAK-only versions of their software, so that you have a
choice between an easy to use system with GAK support, or a difficult
and balky product like PGP 2.6.2, distributed via underground means and
with GAK workarounds.  Now at last you can be sure that even if the very
worst happens, you will at least have the convenience and ease of use of
PGP 5.0 as the GAK disabled product, via a non-GAK international version.
This doesn't have anything to do with PGP's policies or motives; it is
strictly because of PGP 5.0's source distribution, which will make it
easy for cypherpunks to modify it to look compliant with GAK while using
superencryption or some other technology to avoid it.

No longer will it be a choice between convenient GAK or clumsy non-GAK,
opening the latter option only to cypherpunks and hackers.  Now people
opposed to GAK will be guaranteed an option of making their software at
least as easy to use as PGP 5.0.  If source code becomes available for
PGP 5.5, that will raise the guaranteed ease of use of non-GAK software
even further (by all accounts, 5.5 has an even better interface than 5.0).

The existence of these products in source code form will forever stand
as a barrier to any hope to coax (most) people into using GAK software
by forcing it into built-in products, leaving the alternative of non-GAK
software only to a tiny minority.  This in itself should monkey wrench
any government plans for requiring GAK.






Thread