Lucky Green <shamrock@cypherpunks.to> writes:
On Tue, 14 Oct 1997, Tim May wrote:
And as Schneier noted yesterday, the support by PGP for "message recovery" is already being used by Congress as an arguing point that it is indeed practical and should be made mandatory.
I missed that one.
They're right too that it is possible (though less secure). That's the purpose of the anti-GAK design principles, see [1] below. They codify a design process for how to fuck with: - protocol designs - standardisation processes - implementations to make them as GAK-hostile as possible. There is a scale from: pro-GAK: (USG, NSA, TIS, IBM) (give me video cams in all bedrooms) GAK neutral: (implementer who just implements ignoring political argument of whether or not GAK will come in believing it irrelevant) GAK-hostile: (implementer who is rabidly anti-GAK, and wants to stop the GAKkers at all costs; he wants to manipulate protocol standards settings processes to ensure what results is not just `not GAK' if implemented in one way, he wants to make sure that it is impossible to be both conformant to the standard and implement GAK, then he wants to implement to that anti-GAK-infiltrated standard and deploy as many of his units as possible all implemented as GAK-hostily as possible, with user ergonomics, functionality and presentation m$ would die for). I really truthfully am completely puzzled as to PGP. They make nice pro-privacy rants (eg Jon Callas), but yet they are implementing a GAK compliant system, and one which can also be used to itself fullfill full GAK requirements without any software modifications. It could literally be plugged in tommorrow. This is inconsistent. Then myself, Tim May, Peter Trei, Bruce Schneier, Peter Gutmann, and most of the rest of cpunks, and OpenPGP, go over and over what is wrong with it, how to do it in non-GAK pervertable ways, or not to do it at all. And pgp _doesn't get it_. I am non-plussed. Are we suffering group hallucination here and are we all totally confused? Or is something very strange going on insde pgp's building? What _is_ going on in there? Are they arguing? Are they blissfully ignorant that the GAKkers are applauding their efforts? Has the corporate mind set take over? Have they done a deal with the Feds? Have they got $ signs in front of their eyes and forgotten that they were once pro-privacy (those that ever were; I guess some of the are just various suits). I thought they were supposed to be on our side?
[Just spent four days at an intensive training improving my fail-safe skills].
`fail-safe'? As in blowing holes in cardboard cutouts with `fed' written across them at 50 yds with a large bore weapon full of hollow-points? Sounds phun :-) Another form of backup plan is to get the fuck out when GAK hits. Go move to switzerland, or anguilla or somewhere from which to continue your after the fact monkey wrenching. (Is switzerland any good? Only place other than UK I have citizenship -- actually not true have US two through wife dual nationality, but I'm not sure about US right now -- may get to GAK before UK lot do). (pls excuse if `fail-safe' means something entirely unrelated, I'm not familiar with the euphamism/technical term). Adam [1] ====================================================================== Date: Tue, 14 Oct 1997 10:37:21 +0100 From: Adam Back <aba@dcs.ex.ac.uk> To: ietf-open-pgp@imc.org Cc: cypherpunks@cyberpass.net Cc: cryptography@c2.net Subject: proposal: commercial data recovery If we take the design goal of designing a commercial data recovery system which is not GAK compliant, we can most succinctly state this design goal as the task of ensuring that: - at no point will any data transferred over communications links be accessible to anyone other than the sender and recipient with out also obtaining data on the recipient and/or senders disks I think we can distill the design principles required to meet the design goal of a non-GAK compliant Corporate Data Recovery (CDR) system down to ensuring that: 1. no keys used to secure communications in any part of the system are a-priori escrowed with third parties 2. second crypto recipients on encrypted communications are not used to allow access to third parties who are not messaging recipients manually selected by the sender 3. communications should be encrypted to the minimum number of recipients (typically one), and those keys should have as short a life time as is practically possible Included in 2) is the principle of not re-transmitting over communication channels keys or data re-encrypted to third parties after receipt -- that is just structuring -- and violates design principle 2. With these three principles you still have lots of flexibility because you can escrow storage keys, do secret splitting of storage keys, and store keys encrypted to second storage accessors on the local disk for stored data recovery purposes. As an additional bonus, principle 3 adds extra security against attackers gaining access to encrypted traffic after the fact -- the recipient no longer has the key -- this is a form of forward secrecy. Systems designed to the CDR design principles are of significantly less use to GAKkers than PGP Inc's GAK compliant Commercial Message Recovery (CMR) design. The CDR design significantly hinders the take up of GAK if widely deployed. Design principle 3 -- forward secrecy -- is inherently hostile to GAKkers, and is the strongest statement you can make against GAK: you are purposelly _destroying_ communications keys at the earliest possible moment to ensure that GAKkers can not obtain the keys by legal and extra-legal coercion, black mail, and rubber hose cryptanalysis. The whole system translates into the Feds having to come and physically take your disk to obtain information about you, which is much better than GACK, and not what the GAKkers are interested in at this point. The GAKkers would like to install themselves, and coerce companies into installing for them (via GAKker/USG/NSA/NIST organised efforts such as the 56 bit export permit for companies installing key escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)). I fear that PGP Inc's CMR proposal inadvertently meets most of the NIST/NSA specified KRAP requirements. What the GACKers want is systems where they can perform routine key word scanning and fishing expeditions into your communications from the comfort of their offices, without your knowledge. This is push button Orwellian government snooping. Within the constraints imposed by the CDR design principles, there is plenty enough flexibility to acheive the commercial data recovery functionality to similarly weak levels of enforcability as achieved by the CMR design. Weak levels of enforceability are appropriate because there are other exceedingly easy bypass routes: super-encryption, and walking out of the office with a DAT tape. I would like to organise a collaborative effort to write a white paper discussing how to implement various functionalities using the CDR design principle. Then I would like to see discussion of which set of these functionalities which best acheive the user requirement for company data recovery. Lastly I would like to see a collaborative development effort to provide a example implementation of a CDR system which can be used as a discussion point for the OpenPGP standardisation process. I suppose the best place to discuss this process is the IETF forum for discussion of the OpenPGP standard, the OpenPGP mailing list (subscribe by sending message body "subscribe ietf-open-pgp" to "majordomo@imc.org"). I have already had people express in email to me their interest in doing this. Those people can speak up if they want to. Technical input is sought from people opposed to GAK compliant software, and from PGP Inc, and others defending PGP's GAK compliant CMR proposal. 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`