[119093] in Cypherpunks
strategy in the GAK skirmish
daemon@ATHENA.MIT.EDU (Adam Back)
Thu Oct 14 19:23:55 1999
Date: Fri, 15 Oct 1999 00:08:34 +0100
Message-Id: <199910142308.AAA00434@server.cypherspace.org>
From: Adam Back <adam@cypherspace.org>
To: raven@ietf.org
Cc: cypherpunks@cyberpass.net
Reply-To: Adam Back <adam@cypherspace.org>
[Cc: cypherpunks -- discussion of whether IETF should become involved
in building tracing and tapping etc into protocols at:
http://www.ietf.org/mailman/listinfo/raven ]
Let's talk about strategy and tactics.
For whatever motives (biased view point, job security, preservation of
ECHELON and spook mass eavesdropping ability) the spooks are one will
have noticed by now after 5 years or so of onslaught rather desperate
to shove tapping and eavesdropping down our collective throats.
I think early in the clipper I debate statistics were gathered which
showed that the public doesn't want this.
The FBI, spooks and LEAs are putting serious tactical planning into
their efforts. They are endlessly inventive in their attempts to
rename and do PR remakes of the basic demand: they want access to
crypto keys (GAK = Government Access to Keys).
I would calmly and seriously suggest that in this context it wouldn't
be that far fetched to suspect that several of the more eloquent
participants on this list may be NSA hired PR flaks.
Of course there are also the less directly hired NSA PR flaks: those
who's jobs or interests are tied to defense contractors who feel
obliged to do lip service to their paymasters political demands.
Plus one presumes a number of individuals who are socialists who
believe that the nanny state should micromanage the security and
safety of individuals, by massively trading off privacy and freedoms
for marginal security increments.
I'd be interested in opinions on the most effective strategies from
our point of view, to prevent this onslaught.
What can the crypto hacker, protocol designer, policy wonk, and
company executive do about this. I think readers need to think much
more subversively; the opposition is hiring serious PR, and is blowing
billions out of tax payer money trying to obtain the demanded powers.
That our side has largely prevailed thus far is a credit considering
the imbalance of funds spent on the government side vs the individual
and business side.
Some time ago during the discussion of a recovery mode for
ietf-open-pgp I wrote the following, which I think applies equally
well to the current discussion:
http://www.cypherspace.org/~adam/grdesign/
it is a discussion of "GAK resistant design principles for crypto
protocol designers, implementors and standards people".
Product and protocol designs, standards and protocols can have a major
influence on political outcomes for decades afterwards. A protocol,
design or implementation using a protocol itself can be neutral, or
even hostile in it's design to attempts at subsequent insertion of
backdoors. Examples might be:
- the use of aggresive forward secrecy with short lived keys;
- end to end forward secrecy (users control forward secret keying
themselves in software);
- deliberate design or implementation features designed to make
interoperability with backdoored systems problematic
and so forth.
Drawing from the above types of strategy and the previous failures of
the Clipper attacks, I think that our aims are to make sure it *is*
impractically expensive, that it doesn't interoperate, and to do what
we can do exarcerbate these problems and promulgate the use of these
strategies. Damage functionality of systems using it, actively ensure
non backdoored software or protoocls which could interoperate doesn't
or can't.
There is lots of scope here.
I suspect these kinds of activities have already been occuring in a
fairly disorganised distributed fashion -- few technical people like
the idea of government backdoors, master keys etc.
> It will/would also be interesting to hear what sort of policy
> stance the ISOC, IESG, and IAB will have on this issue next
> month. ;-)
I am hoping that ISOC, IESG and IAB will say they are not going to
have any involvement with this.
Any other stance would be a complete U-turn on prior policy, and I
think the no-involvement stance does most to frustrate deployment of
government backdoors.
Adam
[1] http://www.cypherspace.org/~adam/grdesign/
======================================================================
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
precover 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.
