GR (GAK Resistant) Design Principles

If we take the design goal of designing systems including confidentiality which are resistant to government plans for GAK, we can 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 messaging recipient with out also obtaining data residing on storage devices under the recipient or senders control

We can derive design principles useful in maximising the GAK resistancy (GR) property from this goal:

principle 1: no keys used to secure communications in any part of the system are a-priori escrowed with third parties

principle 2: second crypto recipients on encrypted communications should not be used to allow access to third parties who are not messaging recipients manually selected by the sender

principle 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

principle 4: deployment wins. Violating any of principles 1, 2 or 3 whilst still remaining better than GAK-neutral can be justified where deployment is thereby increased to the extent that the reduced GAK resistance of the product can be justified by the overall increase in GAK resistancy in the target jurisdictions. This can be expressed loosely as the equation:
introduced resistancy = deployment x resistancy rating

Corollaries

Corollary 1: Included in design principle 2) is the principle of not re-transmitting keys or data after decryption to third parties -- that is just structuring -- and violates design principle 2.

Corollary 2: where communications are transmitted in ways which violate principles 1, 2 or 3 it is in general more GAK resistant to enforce as far as possible that the recovery or escrow information remains in as close proximity to the data as possible, and as much under the control of the user as possible.

Corollary 3: where communications are transmitted which violate principles 1, 2 or 3 it is in general more GAK resistant to make these communications as difficult to automate as possible. For example no scripting support is given thereby weakly enforcing that GUI user interaction is required, and/or that the recovery process is made artificially time consuming (by not storing all bits of the key thereby weakly forcing the use of brute force to recover the key), and/or that the communication could use non electronic, or hard to automate communication channels

Corollary 4: Where a profit function outside the individuals control interferes with GR maximisation of principle 4, continuing in this environment may be justifiable where this tactic helps promote global GAK resistance in the target jursidiction. Examples of novel ways of making the best of this imposed profit function overlayed on the solution space of designs may be: attempts to subvert standardisation processes to make the standards GAK resistant even for GAK neutral developers, or to code GAK resistant implementations for GR-neutral employers without informing them of these coding decisions, or to promote GR implementation and protocol design to contacts in the cryptographic developer community, or to anonymously release useful proprietary GR optimisation technology, or to sabotage ergonomics or reliability functions in implementations of very low GR rated designs.

This is a work in progress. Comments are sought on clarity, and on correctness. Discussion has been occurring on the cypherpunks and on ietf-open-pgp mailing lists.

Comments to the lists or to me (Adam Back) at <adam@cypherspace.org>