Re: PGP Employee on MKR

> 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.

Anonymous writes:
> [just remove the CMR key and have your message bounce
> 
> People say, "Oh, but then the government will make everybody run the
> policy enforcer and reject any mail not encryped to the government."

Yep.

> 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.

True.  Doesn't mean I'm going to rush off and implement a policy
enforcer to do the job, nor use the good name of PGP Inc to deploy
such software widely.

> Second, it's a ridiculous idea which ignores how email works.  

Nope, it's not.  Enforcement does not have to be 100%.

People smoke various illicit substances; it's illegal: get caught with
your joint, you go to jail.

> 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!

I'm on dial up, here.  I'll be going permanent just as soon as the
damn cost comes down.  ($15k for 64k line over here, you've got to be
kidding).

> People say, "Oh, but they'll make it illegal to receive mail at home
> without going through an ISP."  

Most users are going via an ISP right now.

> 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.

Nope.  All that is required is for the sending of non-CMR encrypted
emails to be detectable.  Super-encryption doesn't cut it -- the
government is going to notice that, after they've singled you out for
a spot check.

> 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.

Lots of things are illegal which it is easy to get away with most of
the time.  Still doesn't make it a good idea to write software which
makes it easier to do spot checks, does it?

> 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?

Neither of those cut it.  If your company is sampling your email, and
you've hacked around it, they'll just fire you, or what ever.

If it is the government doing the sampling, they'll just lock you up,
or tack 5 years on to the sentence for "use of non GAKed encryption in
furtherance of a crime".

> 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.

Sure.  But just because this is possible doesn't mean you should do
it.  The gap between me doing it, and PGP doing it is that PGP are
shipping hundreds of thousands of the things.  Deployment wins.

> 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.

Maybe.  The point is that if pgp5.5 didn't include it this extra
deployment hurdle would be the government's problem.  Users would be
using older mail systems for ages.

> 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,

Nope.  Never said that.  You can remove them all you like -- your mail
just bounces when you do.

> forcing everyone to run SMTP filters, 

not required.

> making it illegal to receive email at home, 

not required.

> preventing people from implementing clients with workarounds,

not that much of a big deal; most users have enough problems just
getting out of the box software to work without downloading cypherpunk
patches, knowing what they are etc.  Ie we _know_ that cypherpunk
types will be ok.  That's not the point.

> changing the technology to make it harder to implement workarounds
> using binding cryptography.  

That's an optional.

> 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.

So could clipper.  Where you defeneding it too?  It was optional (or
so they said), etc.

Think about detection rather than hackign around once things become
laws with associated jail times.

> [source code, non-GAKked freeware]
>
> 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.

I think you'll find that the majority of users will use the GAKked
stuff.  Most users are using windows.  Most are using 40 bit crypto.

Adam
-- 
Now officially an EAR violation...
Have *you* exported RSA today? --> http://www.dcs.ex.ac.uk/~aba/rsa/

print pack"C*",split/\D+/,`echo "16iII*o\U@{$/=$z;[(pop,pop,unpack"H*",<>
)]}\EsMsKsN0[lN*1lK[d2%Sa2/d0<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<J]dsJxp"|dc`

<><

e-mail:  maxson1@marshall.edu
www:     http://webpages.marshall.edu/~maxson1

My ham call is KC8CDT.