From: "Attila T. Hun" <attila@hun.org>
Date: Tue, 14 Oct 1997 06:12:15 +0800
To: Adam Back <hal@rain.org
Subject: Re: CMR paves the road to GAK, and provides no corporate security.
In-Reply-To: <199710121053.LAA01120@server.test.net>
Message-ID: <19971013.170615.attila@hun.org>
MIME-Version: 1.0
Content-Type: text/plain



-----BEGIN PGP SIGNED MESSAGE-----

    original message(s) follow my comments:

    1.  agreed that GAK is awful from a security standpoint. it is just
        a huge hole open to abuse by supposedly trusted escrow agents and
        the usual government dishonesty and deceit.

        on top of that, GAK is an unpardonable sin, with CAK not far
        behind.

    2.  CMR does not lead to GAK. let's get the terms correct as to what
        can be done, versus what will be done.

        a)  there will be companies who start with GAK/CAK since it is
            simple to issue an order of compliance.

        b)  there will be companies who need to maintain content audit
            trails a) to prove they either did or did not do as stated,
            b) development records, etc. for instance for patents, c)
            historical customer records.

            hopefully this class will use signature, communications,
            and individual or group storage keys.  the need for encryption
            is paramount on computer systems --it is the equivalent of
            the locked file cabinet, sometimes in a locked secure area.

        c)  PGP today can meet the requirements of GAK, CAK, CMR, or
            just about any format you wish --and make corporate control
            a reality. 

            I could have a crude, but workable control program which would 
            prevent the use of pgp standalone as well --and I could have it
            up and running by tonight.

            secondly, add a few modifications to sendmail, and trying to
            slip one through the system is history.

    stating that CMR leads to GAK is the same argument that mary jane
    starts the victim on the road to horse.  

        -how's that allegorical illusion to blow by keyword scanners?

    likewise, I still believe I would much rather see PGP, Inc. implement
    a SNMP system to mandate corporate policy which can be adjusted from
    zero for the libertarians to GAK for the unpardonable sinners.  at
    least the employees of the latter can protest the ignorance of 
    management; despite the general attitude that all management personnel
    are the south ends of northbound horses, management is interested in
    calm, productive employees.

    if the government does mandate GAK, and really gets serious about
    enforcing it, there will be a lot of changes, and I for one will
    trade my computer for something more necessary as I build a bunker to     
    protect myself and children --there will be no government about that 
    time, or at least a government we will recognize.

        attila out, again


-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: latin1
Comment: No safety this side of the grave. Never was; never will be

iQCVAwUBNEJawL04kQrCC2kFAQHBCQQAqr0jk2wilOVAx83ZBEyU9ZLzFp0WVk9F
AoWlZwefOxngL+iCZbalLdrr94CECmLes3ugmbDukQfyminSlFsVVSKMkRD64uRm
91giq52/FUPjH4mE1IJZsj/07F0/slydkDcsBI7awfvl8VFxbAGF0oJDY4fAHlz9
ZBpxvSoPewo=
=jdGv
-----END PGP SIGNATURE-----

on or about 971012:1153 
    Adam Back <aba@dcs.ex.ac.uk> was purported to have 
    expostulated to perpetuate an opinion:

+[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


 --
 "When I die, please cast my ashes upon Bill Gates. 
     For once, let him clean up after me! " 

 "Experience keeps a dear school, but fools will learn in no other."     
        --Benjamin Franklin
 ______________________________________________________________________
 "attila" 1024/C20B6905/23 D0 FA 7F 6A 8F 60 66 BC AF AE 56 98 C0 D7 B0