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