From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 15 Oct 1997 15:06:41 +0800
To: shamrock@cypherpunks.to
Subject: Re: Just say "No" to key recovery concerns...keep OpenPGP pure
In-Reply-To: <Pine.BSF.3.96.971015054500.18802A-100000@pakastelohi.cypherpunks.to>
Message-ID: <199710150550.GAA11404@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




Lucky Green <shamrock@cypherpunks.to> writes:
> On Tue, 14 Oct 1997, Tim May wrote:
> > 
> > And as Schneier noted yesterday, the support by PGP for "message recovery"
> > is already being used by Congress as an arguing point that it is indeed
> > practical and should be made mandatory.
> 
> I missed that one. 

They're right too that it is possible (though less secure).

That's the purpose of the anti-GAK design principles, see [1] below.
They codify a design process for how to fuck with:

- protocol designs
- standardisation processes
- implementations

to make them as GAK-hostile as possible.

There is a scale from:

pro-GAK: (USG, NSA, TIS, IBM) (give me video cams in all bedrooms)

GAK neutral: (implementer who just implements ignoring political argument of
  whether or not GAK will come in believing it irrelevant)

GAK-hostile: (implementer who is rabidly anti-GAK, and wants to stop
  the GAKkers at all costs; he wants to manipulate protocol standards
  settings processes to ensure what results is not just `not GAK' if
  implemented in one way, he wants to make sure that it is impossible to
  be both conformant to the standard and implement GAK, then he wants to
  implement to that anti-GAK-infiltrated standard and deploy as many
  of his units as possible all implemented as GAK-hostily as possible,
  with user ergonomics, functionality and presentation m$ would die for).

I really truthfully am completely puzzled as to PGP.  They make nice
pro-privacy rants (eg Jon Callas), but yet they are implementing a GAK
compliant system, and one which can also be used to itself fullfill
full GAK requirements without any software modifications.  It could
literally be plugged in tommorrow.  This is inconsistent.

Then myself, Tim May, Peter Trei, Bruce Schneier, Peter Gutmann, and
most of the rest of cpunks, and OpenPGP, go over and over what is
wrong with it, how to do it in non-GAK pervertable ways, or not to do
it at all.

And pgp _doesn't get it_.

I am non-plussed.

Are we suffering group hallucination here and are we all totally
confused?  Or is something very strange going on insde pgp's building?

What _is_ going on in there?  Are they arguing?  Are they blissfully
ignorant that the GAKkers are applauding their efforts?  Has the
corporate mind set take over?  Have they done a deal with the Feds?
Have they got $ signs in front of their eyes and forgotten that they
were once pro-privacy (those that ever were; I guess some of the are
just various suits).

I thought they were supposed to be on our side?

> [Just spent four days at an intensive training improving my
> fail-safe skills].

`fail-safe'?  As in blowing holes in cardboard cutouts with `fed'
written across them at 50 yds with a large bore weapon full of
hollow-points?  Sounds phun :-)

Another form of backup plan is to get the fuck out when GAK hits.  Go
move to switzerland, or anguilla or somewhere from which to continue
your after the fact monkey wrenching.  (Is switzerland any good?  Only
place other than UK I have citizenship -- actually not true have US
two through wife dual nationality, but I'm not sure about US right
now -- may get to GAK before UK lot do).

(pls excuse if `fail-safe' means something entirely unrelated, I'm not
familiar with the euphamism/technical term).

Adam

[1]
======================================================================
Date: Tue, 14 Oct 1997 10:37:21 +0100
From: Adam Back <aba@dcs.ex.ac.uk>
To: ietf-open-pgp@imc.org
Cc: cypherpunks@cyberpass.net
Cc: cryptography@c2.net
Subject: proposal: commercial data recovery

If we take the design goal of designing a commercial data recovery
system which is not GAK compliant, we can most 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 recipient with out
  also obtaining data on the recipient and/or senders disks


I think we can distill the design principles required to meet the
design goal of a non-GAK compliant Corporate Data Recovery (CDR)
system down to ensuring that:

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

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

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

Included in 2) is the principle of not re-transmitting over
communication channels keys or data re-encrypted to third parties
after receipt -- that is just structuring -- and violates design
principle 2.


With these three principles you still have lots of flexibility because
you can escrow storage keys, do secret splitting of storage keys, and
store keys encrypted to second storage accessors on the local disk for
stored data recovery purposes.

As an additional bonus, principle 3 adds extra security against
attackers gaining access to encrypted traffic after the fact -- the
recipient no longer has the key -- this is a form of forward secrecy.


Systems designed to the CDR design principles are of significantly
less use to GAKkers than PGP Inc's GAK compliant Commercial Message
Recovery (CMR) design.  The CDR design significantly hinders the take
up of GAK if widely deployed.  

Design principle 3 -- forward secrecy -- is inherently hostile to
GAKkers, and is the strongest statement you can make against GAK: you
are purposelly _destroying_ communications keys at the earliest
possible moment to ensure that GAKkers can not obtain the keys by
legal and extra-legal coercion, black mail, and rubber hose
cryptanalysis.

The whole system translates into the Feds having to come and
physically take your disk to obtain information about you, which is
much better than GACK, and not what the GAKkers are interested in at
this point.  The GAKkers would like to install themselves, and coerce
companies into installing for them (via GAKker/USG/NSA/NIST organised
efforts such as the 56 bit export permit for companies installing key
escrow; and efforts such as the Key Recovery Parners Alliance (KRAP)).
I fear that PGP Inc's CMR proposal inadvertently meets most of the
NIST/NSA specified KRAP requirements.

What the GACKers want is systems where they can perform routine key
word scanning and fishing expeditions into your communications from
the comfort of their offices, without your knowledge.  This is push
button Orwellian government snooping.

Within the constraints imposed by the CDR design principles, there is
plenty enough flexibility to acheive the commercial data recovery
functionality to similarly weak levels of enforcability as achieved by
the CMR design.  Weak levels of enforceability are appropriate because
there are other exceedingly easy bypass routes: super-encryption, and
walking out of the office with a DAT tape.


I would like to organise a collaborative effort to write a white paper
discussing how to implement various functionalities using the CDR
design principle.

Then I would like to see discussion of which set of these
functionalities which best acheive the user requirement for company
data recovery.

Lastly I would like to see a collaborative development effort to
provide a example implementation of a CDR system which can be used as
a discussion point for the OpenPGP standardisation process.

I suppose the best place to discuss this process is the IETF forum for
discussion of the OpenPGP standard, the OpenPGP mailing list
(subscribe by sending message body "subscribe ietf-open-pgp" to
"majordomo@imc.org").

I have already had people express in email to me their interest in
doing this.  Those people can speak up if they want to.  Technical
input is sought from people opposed to GAK compliant software, and
from PGP Inc, and others defending PGP's GAK compliant CMR proposal.

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`