1997-10-16 - Re: anti-GAK design principles: worked example #1

Header Data

From: Adam Back <aba@dcs.ex.ac.uk>
To: hoffmang@pgp.com
Message Hash: 8f3a692279a41fe236300f2146f674ce06c6c080f364738cccb2d15585b4b3c4
Message ID: <199710160711.IAA00177@server.test.net>
Reply To: <Pine.LNX.3.95.971015160918.16789K-100000@privnet.pgp.com>
UTC Datetime: 1997-10-16 07:43:42 UTC
Raw Date: Thu, 16 Oct 1997 15:43:42 +0800

Raw message

From: Adam Back <aba@dcs.ex.ac.uk>
Date: Thu, 16 Oct 1997 15:43:42 +0800
To: hoffmang@pgp.com
Subject: Re: anti-GAK design principles: worked example #1
In-Reply-To: <Pine.LNX.3.95.971015160918.16789K-100000@privnet.pgp.com>
Message-ID: <199710160711.IAA00177@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Gene Hoffman <hoffmang@pgp.com> writes:
> On Wed, 15 Oct 1997, Adam Back wrote:
> 
> > 
> > - store a copy of the private half of the users PGP encryption key
> >   encrypted to the company data recovery key on the users disk.
> > 
> 
> You would rather have PGP implement private key escrow?

Yes.  

This is less GAK friendly than the way that PGP are implementing CMR.

In worked example #2 and I might do a #3 as well, I will as promised
show you how to apply the design principles to achieve greater
GAK-hostility than example #1 which you are objected to above.

However, in the mean time, I would like you and other PGPers to
re-read my post and answer the questions contained in it:

> - can you see ways that this could be perverted to implement GAK
>   (yes I can too, btw, but...)
> - are those ways logisitically harder for GAKkers to acheive than for CMR

You appear to claim that your answer to the second question is no.

I would like to see you explain your reasoning for why this is so.

You may find it constructive to re-read some of Tim May's recent posts
as he explains the logic of this fairly clearly.  Tim May does not
need the anti-GAK design principles to think in an critical
GAK-hostile way.

PGP Inc does appear to need them because their design principles are
currently at best GAK-neutral, and appear to be largely based on
wooly, ill thought-out pro-privacy / liberal thinking.

You have to think in a crypto-anarchist, saboteur mindset to maximise
your ability to prevent mandatory GAK becoming reality.  The anti-GAK
design principles are a codification of the crypto-anarchist GAK
saboteur's natural predilections to want to prevent the GAKkers.

I have in waiting some other design principles which codify more
general crypto-anarchist design principles.  I will not be adding
these to the anti-GAK design principles at this stage for fear of
confusing the first issue: how to best prevent GAK occuring in our and
other 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`






Thread