From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 16 Oct 1997 23:43:27 +0800
To: gbroiles@netbox.com
Subject: Re: Security flaws introduced by "other readers" in CMR
In-Reply-To: <3.0.3.32.19971015183740.008cad00@mail.io.com>
Message-ID: <199710161530.QAA22810@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Greg Broiles <gbroiles@netbox.com> writes:
> Tim May <tcmay@got.net> wrote:
> 
> >Truly sensitive stuff--stuff about takeovers, foreign production plans, new
> >products, etc.--will be encrypted with channels having no nosy security
> >guards or Corporate Crypto Compliance Police silently listening in.
> >
> >Which means we're back to square one. So why does PGP, Inc. bother?
> 
> Because they've got customers who will pay for CAKware. 

I have tried to express this trade off, and to make suggestions of how
to work within this frame work to hinder GAK take up:

(from http://www.dcs.ex.ac.uk/~aba/grdesign/:)

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

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.

> Why will customers pay for it? Same reason the FBI wants GAK, even though
> motivated/well-informed crypto users will superencrypt or otherwise bypass
> the enforcement mechanisms. If you're the C in CAK or the G in GAK, access
> to some data is better than access to no data - and the possibility of
> enforcement radically alters the risk/benefit calculus of even intelligent
> actors who see their interests as contrary to those of the [C,G]. 

I agree.

> As Jon Callas confirmed at the recent Cpunks physical meeting, the current
> CAK/CAM/whatever system has very weak code re policy enforcement - for
> example, it'll allow otherwise forbidden messages to pass through its
> filters if even the "--- BEGIN PGP MESSAGE ---" lines are altered or
> removed. It won't disassemble tar or zip or uuencode packages, or otherwise
> attempt to discover simple attempts to bypass the enforcement mechanisms.
> They're not trying to stop determined covert communicators - that's not
> their threat model.

It is a property of fielded systems that the majority of users will
work within the functionality provided by it.  This property can be
used by all 3 sides of the debate.  It is a politically neutral
mechanism.

1. It can be used by PGP Inc (who evaluate the tradeoffs between
socially desirable properties and ergonomics and come up with the
belief that CMR optimal solution).  They point out (rightly) that the
fact it is possible to easily hack around demonstrates some GAK
resistance.  I would argue however that it is not a very great
addition.  I have been trying to persuade PGP Inc that it is possible
to implement more highly GAK resistant products within their profit
function and user requirement set using the CDR (corporate data
recovery).

2. It can be used by people such as us who consider different
tradeoffs to be optimal, in that we can field systems which make it so
that the system has to be hacked before it could be used for GAK.  The
obfuscation can always be hacked around, almost by definition, but a
large beaurocratic organisation such as a government will find it
difficult logisitically to organise the development of GAK enabling
patches, and deploy these, and to persuade people to apply the
patches.

3. It can be used by people such as perhaps TIS who have cost
functions highly sensitive to not upsetting the government, and
therefore field on behalf of government GAK enabled systems.  They can
make it as hard to hack around as they can.  The difficulty of hacking
around and the difficulty of widely deploying the cypherpunks
"anti-gak patch for TIS mandatory GAKware v1.0" means that they partly
succeed.

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`