Zooko Journeyman <zooko@xs4all.nl> writes:
Adam, I applaud your effort to steer discourse toward productive work re: GAK, CMR, CDR. I haven't thought about your idea enough to have a definite opinion, but at first blush it seems a promising strategy to design high-security and forward-secrecy for communication but recovery/sharing features for stored data.
Thank you. I would encourage others to read the proposal, and provide criticisms of it.
I wonder if it is too much early-days to start talking about advanced protocols e.g. secret-splitting in IETF-Open-PGP? Probably so. Better just punch out a standard with current tech...
I agree entirely. The motivation for attempting to formalise the CDR design principles, and for exploring designs which are non-GAK compliant is based on these lines of reasoning, that we should: 1. Persuade PGP Inc that there are less GAK friendly ways of implementing data recovery 2. If that argument fails, and in the event that PGP were to try to influence the IETF OpenPGP forum to adopt any features relating to pgp5.5 GAK compliant functionality into the OpenPGP standard that we have an alternate proposal well enough thought through to compete with PGP's CMR proposal with sound technical arguments. 3. Of improving the state of the technology by working to include forward secrecy as much as possible into secure email messaging. This is a very effective method of giving the bird to the GAKkers, by purposefully destroying communications keys as soon as possible after the fact. This is consistent with the CDR design goal: make the GAKkers job as difficult as possible. Frustrating the GAKkers is a fun, morally satisfying activity.
Hm. What about the idea of storing your data remotely (for cost-efficiency, safety, etc.) using encryption to maintain your privacy? In that case, the distinction between comms and storage keys is blurred. A company may choose to e.g. store all long-term data at Zooko's Backup Server, encrypted in such a way that some combination of corporate keys (controlled by individual employees and/or departments) is necessary to decrypt each package of data. This would open the door, as you fear, for a government to mandate that _its_ key be added to each set, with authority to open any package even without the cooperation of any corporate keys.
The application you describe has very interesting implications for the CDR vs CMR debate. I think that one way that you could implement remote backup in a way which is sympathetic to CDR design principles like this: - The communications security aspect could be acheived via the normal design for securing communications derived from the CDR design principles. That is using short lived communications keys with no third party access to communications in transit without access to hard disks at either end. - The data would be super-encrypted to the companies backup recovery storage key(s). This technically violates the CDR design goal and principles of not allowing third party access to communicated data, super encryption doesn't negate this, it is just more structuring. However, super-encryption does minimise the damage by preserving CDR principle that recovery of data should require physical compromise of one or both end points, which I think is an important principle, and a useful property in this case. This lesson leads to the corollary to the CDR principles that: - if you can't keep to the principle of not transmitting data with third party recovery information attached, that: - super-encryption of the transmitted recoverable data can be used to at least preserve the requirement for one or both ends of the communication to be compromised to effect third party access. But still, the remaining way that this system could be perverted would be as you say for the GAKkers to demand to be one of the storage accessors for the encrypted disk backup, and for the GAKkers to then attempt to coerce the remote storage service provider to hand over the ciphertext, or for the government to set themselves up as a central provider of off site backup services. The GAKkers desire for automatic access to communicated storage data is frustrated to the maximal extent possible by those CDR design principles we have managed to retain. To achieve automated access the GAKkers must start replacing software, and we have prevented automatic snooping of our backup data whilst it is in communication, with software we have fielded. - CDR design principles do not prevent someone modifying software, but as we all know deployed systems are additional obstacles to overcome: they have to coerce some company in to implementing the new software with built in GAK, and they have to coerce everyone into replacing their existing software with this unpopular new software. Widely deployed systems can be large obstacles. The mess the US IRS in with their millions of lines of hard to modify source attest to this fact. The IRS scenario has some lessons for us, for possible additional CDR design principles: - keep the source code out of reach of GAKkers so that they can not coerce us so easily to modify it. Off shore backup might be useful; destroy the backup recovery key if GAK comes in. - make systems non-interoperable where this does not interfere with functionality - have mandatory GAK company contingency plans such as moving the company to Switzerland. That first suggestion costs so much in the loss of user access to source code to assure ourselves that there is no backdoor that we probably can't employ it. The other two look like sound principles to me.
Zooko's Backup Server can be physically located in a country free of such intrusive organizations, but of course it is the intrusive organizations of the _client's_ country that become important with that kind of protocol...
One comfort which can be drawn from the above design using super encryption inside a communications envelope protected with short lived non-escrowed communication keys, is that the fielded software could not be used as-is to prevent the practice of jurisdiction shopping. Another comfort is that companies can, even if forbidden from using offshore remote backup facilities, simply stop using remote backup facilities at all, unless the GAKkers really go overboard and demand that all citizen units will run this government remote backup software to upload diffs of their disks to government run backup services. I'm sure they would love to do that, and charge you for the "service" too. Also I expect there would be significant political hurdles for the GAKkers to overcome in mandating government run remote backup services for citizen units, or even for companies in our countries. 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`