From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sun, 12 Oct 1997 19:07:12 +0800
To: trei@relay-1.ziplink.net
Subject: Re: CMR paves the road to GAK, and provides no corporate security.
In-Reply-To: <3.0.1.32.19971012005421.007ab570@pop3.ziplink.net>
Message-ID: <199710121053.LAA01120@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




[Padgett, you're Cc'd because I'm quoting something you once claimed
on Perry's list, I think]

I agree with basically every word Peter Trei wrote.  It's not often
you agree with a long post like that 100%, but I could not fault a
single point.

Contrast that to PGP's Jon Callas's recent posts where I found myself
disagreeing with a large proportion of both technical and political
points.

Just a couple of nit-picky comments on various things, and some
re-iteration of the technical arguments against GAK compliancy (to
supplement Peter's good political arguments):

> >* Clipper was a 64-bit key. CMR symmetric keys are full-strength keys (128
> >bits or more), backed with a full-strength public key.
> 
> A word of advice: don't try to discuss Clipper in this forum without checking
> your facts. Clipper used an 80 bit key.

Clipper was definately advertised as a 80bit key, I agree.

But I did once see someone else claim that it was a 64 bit key, and
this was by Padgett Peterson, who is usually pretty good with facts,
though perhaps his claim was speculation in this case.  (I've added
him to the Cc).

His reasoning was that the 16 bit checksum (which Matt Blaze
demonstrated could be brute forced thereby trashing the GAK
enforcement) would come out of the 80bit key size, thereby meaning
that it was only an effective 64 bit key.  I suppose this claim if it
is correct would be similar to DES keys being 64 bit, but 8bits being
parity (checksum again), and therefor being only 56 bit effective.
The DES case would set a precedent for NSA design involvement using
larger "keys" than effective keys.  If this is true, the clipper /
skipjack system was even more flawed than we believed, as not only was
it possible to brute force the checksum, but the key space could have
been brute forced also, possibly without knowing the algorithm either,
just by buying lots of clipper chips (though I think this would
require knowledge of the checksum algorithm).  But clearly the NSA
could have brute forced the traffic in addition to having back doors.

Of course, I think it likely that the key was actually a 96 bit key
with an effictive key size of 80bits after the 16 bit checksum.

Regardless, if Padgett's speculation is correct, I suspect this is not
what Jon was thinking.

> > * With Clipper, there was a central repository of all the keys. With CMR,
> > there is not. I discussed that in detail in my message, "Why Corporate
> > Message Recovery isn't Key Escrow."
> 
> Once again, you haven't checked the record. Clipper keys were to be split, 
> with different halves going to different government agencies. There were
> fairly elaborate plans to prevent posession of only one half giving an
> attacker an advantage. Thus there were *two* repositories, not one. 
> (From the point of view of the paranoid, this was not much of a
> comfort - both repositories belonged to the same entity.)

I must defend Jon a little bit here in that it was fairly widely
agreed that the wording in some of the Clipper documents (perhaps
FOIAed, perhaps released normally, don't know) that the NSA would have
an extra access for "national security" (there's that magic root
password to the constitution again).  The presumtion a lot of people
held was that the NSA would have a second unified copy of the split
databasee to enable this national security access.  I'm not sure of
course that this is actually ever explicitly admitted anywhere, and it
could be that they would just have direct access to both split
databases, but I wouldn't really have thought this was the likely; I
suspect the NSA would've wanted access without others even with in
special wire-tapping courts knowing their tapping activities.

Whether or not this is what Jon was referring to I don't know.


I agree with the negative political aspects Peter expressed of PGP's
"GAK compliancy" (as I like to call it) in PGP's pgp5.5 & SMTP policy
enforcer.

I also think there is a purely technical security case to be made
against this architecture which I have tried to lay out clearly in my
post titled:

	Subject: negative security aspects of GAK compliancy

Peter made some security points about this also.  I think we should be
able to win the argument about GAK compliancy purely on technical
reasons.

The only vaguely logical objection I've seen to arguing against GAK
compliancy on political grounds was Hal Finney's assertion that
OpenPGP should move towards more generalised forms of key assertions
in the form of PolicyMaker-like key assertions (Matt Blaze has a paper
and system called PolicyMaker).

However PolicyMaker I suspect will be a long time coming, and may not
be supported by all vendors due to complexity, and in addition even
with PolicyMaker, the same political and security arguments against
actual use of PGP Inc's GAK compliancy field (or PolicyMaker
assertions to the same effect) still forcefully apply.  And there are
still in particular security and political arguments against
implementing corporate access to mail archives, or corporate
sent/received mail snooping by using the SMTP GAK compliancy policy
enforcer.

Lastly I would comment that it is sad that we on cypherpunks are
having to expend so much energy trying to persuade PGP Inc with it's
supposed pro-privacy stance, and supposedly pro-privacy employees,
that they should be working against GAK, and even to get them to
acknowledge that what they are doing is pro-GAK, and big brotherish is
an uphill struggle.

PGP Inc with their poor PR management, and hugely insensitive pro-GAK
moves mean that PGP Inc is pissing away Phil Zimmermann's good
reputation at a huge rate of knots.

Wake up PGP.  Look what you are becoming.

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`