From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 15 Oct 1997 08:48:12 +0800
To: cypherpunks@cyberpass.net
Subject: why Phil Zimmermann should be speaking out against pgp5.5 and CMR
Message-ID: <199710150017.BAA08707@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




(Readers may notice PRZ's email address on the Cc line, this is an
open letter addressed to him).

In the debate on the controversial pgp5.5 commerical message recover
(CMR) system, I noticed someone made the comment that they couldn't
see what the big deal is with enforced multiple crypto recipients who
aren't also message recipients, as pgp2.x has had non-enforced
multiple crypto recipients for ages.

I will put the case for why this practice should be avoided for
security reasons.

I would like to also put the case of why the enforced multiple crypto
recipient construct should be avoided in building messaging systems
where the designers would like to avoid building GAK compliant
systems.


The security reasoning is simple: there are is an extra door into the
encrypted data: via the CMR key.  Introducing an extra door reduces
security, because there are now two keys which could be compromised to
gain access to the data.

That was simple.  Possibly not that major a problem, perhaps both keys
are so well secured that the additional leakage is academic.  In that
case, fair enough.


Now the GAK compliant case:

Firstly it is important to understand the subtle but very significant
difference between enforced crypto recipients who aren't message
recipients and normal pgp2.x style multiple crypto recipients.

This difference is as much to do with the way that mail clients and
plugins have used the pgp2.x multiple crypto recipients in fielded
systems as with the actual messaging packet differences.

A message recipient is someone who's email address is listed in a To:
Cc: or Bcc: field in your mail client.

A crypto recipient is someone who will be able to decrypt the message.
Pgp is a hybrid crypto system, a message consists of the email
encrypted with a randomly generated symmetric key, the session key.
The session key is in turn encrypted to the public key of the
recipient, these are called Public Key Encrypted (PKE) packets.  To
implement multiple crypto recipients pgp simply tacks on as many PKE
packets as there are crypto recipients; each PKE packet being the
session key encrypted to the public key of one of the crypto
recipients.


Now in most fielded PGP email plugins, and clients which take notice
of Cc: and Bcc: fields, the number of crypto recipients ties directly
with the number of message recipients.

This makes it difficult therefore for the existing systems to automate
encryption to a third party without software modifications.  If a
company which is hoping to become a market leader (a hint PGP) were to
retain this functionality, GAKkers would find it difficult to use this
software to effectively impose GAK.

Sure you can Cc: your message to the NSA key.  This would be voluntary
GAK.  Carl Ellison and a number of others suggested this whimsically
years back.  As in "What's all the fuss about voluntary key escrow,
I'll implement voluntary key escrow for you right now, get DIRNSA to
generate a key, and I'll sign it, and put it on the keyservers -- end
of problem".  Carl Ellison had a very good point.  The government
doesn't want voluntary key escrow, they want as some suspected all
along mandatory key escrow, they want GAK (the GAK term is
coincidentally another Carl Ellison meme).

The reason this is voluntary GAK is that the user in most mail systems
would have to go to some concious effort to do this, and may forget
some of the time.  (It's difficult to make "forgetting" a 5 year
jailable offense).

Now I'm well aware that some email clients, and MTAs will no doubt
allow you to forward copies of all your email transparently to another
party.  (Please don't flood us with replies describing such
functionality).  But this is not really the point; it doesn't matter
if you can forward copies of your encrypted email
"thoughtpolice@nsa.gov" -- they can't decrypt it with out the
recipients key.


Now we come to the danger of PGP Inc's CMR mechanism.

CMR breaks this traditional premise that the crypto recipients
correspond one-to-one with the message recipients.

What it allows is instructions to be given in a public key that tell
the software to encrypt messages intended for the owner of this key to
two message recipients.

This means that for example:

If Phil Zimmermann is using his own companies pgp5.0 mail client (and
I presume he is), that if the US Government were to pass a law
requiring everyone to generate new CMR keys that he would be able to
comply without changing his software.  This is why I would argue that
even pgp5.0 is GAK compliant, it knows how to understand CMR public
keys.

(I am not actually sure if the pgp5.0 mail client can generate CMR
public keys, but the pgp5.5 one can for sure, I'd welcome
clarification on this point).

The new mandatory GAK law would mean that if he didn't generate a CMR
key he would go to jail.  So he complies.  The terms of the law
dictate that the CMR recipeint in individual's mail clients must be
"thoughtpolice@nsa.gov".

Now the next time one of PRZ's favourite resistance groups that he
likes to tell us stories about send him an email thanking him for the
useful piece of software he provided them with, the USG can listen in
because the pgp5.0 software which the resistance fighters have
presumably also upgraded to will understand PRZ's CMR key.  The USG
will if it suits their purposes sell this information to the
government in the originating country, and they will have the death
squads go kill the resistance fighters if they can determine their
identities from the leaked message.

This kind of makes a mockery of what PRZ and the PGP brand stands for.


Now the pgp 5.5 defenders at PGP Inc will jump up at this point and
tell us that this is not so because pgp 5.0 has ability to strip out
the second enforced recipient.  Well it does.  However, PGP Inc has
come up with another related clever innovation: their SMTP policy
enforcer.

This ensures that when resistance fighters attempt to send PRZ email
inside the PGP Inc offices (where they will be presumably field
testing their GAKware software suite), that if they do take off the
CMR recipient, that their mail will bounce.

So not being technical crypto gurus, they will try not taking it off
next time and the NSA will read the mail again, resulting in the
resitance fighters death.

Or perhaps alternatively if they really did want to send him email for
an important reason, like perhaps to warn him that the corrupt
government they were fighting against was going to introduce a law of
mandating the use of pgp5.5 by all ISPs and individuals, they would
have no way to reach him.  This would suit PRZ quite well, because he
probably wouldn't want to hear that.


Actually it is possibly not fair to pick on PRZ, as I consider it
somewhat likely than PRZ is dragging his feet internally to PGP, but
is powerless to stop the corporate mindset now at the helm.  And if so
I apologise for making points at his expense.  But also it is
important that if PRZ is against this move, that he speak up.  That
act would have major significance in altering PGP Incs mind.

It might also result in a parting of the ways, but I understand from
attenders at a physical cypherpunks meeting in the US that PRZ when
quizzed about PGP Inc corporate mentality meaning the company would
eventually sell out to GAK, relayed that he would quit rather than
have be associated with this.

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`