From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 15 Oct 1997 09:57:43 +0800
To: shamrock@cypherpunks.to
Subject: Re: Just say "No" to key recovery concerns...keep OpenPGP pure
In-Reply-To: <Pine.BSF.3.96.971015013850.18390A-100000@pakastelohi.cypherpunks.to>
Message-ID: <199710150138.CAA09580@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:
> > (Disaster planning, for "what if Alice gets hit by a
> > truck?" scenarios, are of course handled by having Alice lock up her
> > private keys in her safe, or perhaps her department manager's safe,
> > whatever. This is a dangerous security flaw, if the key is released, but
> > has the advantage that it's a fairly conventional recovery approach, and is
> > not built into the cryptosystem itself.
> 
> Tim,
> The system above you are proposing is [C,G]AK, plain and simple. This is
> what some companies are doing already. And it is a Bad Thing.

It is GAK pervertable, but it is much more resistant to GAK perversion
than PGP Inc's CMR system.  I think Tim can reason pretty well without
cribbing from the anti-GAK principles, but that he could present
marginally more GAK-hostile systems by using the anti-GAK principles.
(Or perhaps he would figure them out anyway but figures them to be too
complex... my only real claim is that by working to these principles
that it helps clarfiy what you are trying to defend against, and
trying to avoid in your systems).

The reason that you are right that what Tim suggests is GAK
pervertable is that it partly violates one of the anti-GAK design
principles I have been trying to hone.

It violates the principle that recovery information should not be
communicated (via sneaker net on a floppy to the company safe).

It does however obey the corollary that: if you figure you must move
recovery data, you should at least make it inconvenient, avoid
electronic communicated recovery data, and generally require the
recovery data to be as localised as possible.  (Also the principles
state that you should use forward secret comms keys, but I think that
might be pushing it for sneaker net between machines and a laptop in
the safe for ergonomics reasons :-)

Here is how use of the anti-GAK design principles can help to provide
a more GAK hostile system:

It is better to use recovery rather than escrow.  (Encryption of
Alice's private key with a companies recovery key).  This allows you
then to store the recovery information more locally to the data,
closest possible locality to data being another anti-GAK design
principle.

Now how is this harder than GAK?  Heh well you need to use your
imagination and try to make a system designed to fuck with the GAKkers
minds at this point.  Remember not only do you design the system to
not communicate the key automatically, you try your best to prevent it
being removed from the system.

Here's a few ideas:

You store the recovery info on the users disk only, but you do your
damnest to obfuscate it.  Encrypt it with keys hidden in the
executable, obfuscate the code to hell and back, and don't provide
source for that module.  (Obfuscation tricks like interpreter of
encrypted instruction streams ought to take a little bit of
unwinding).

You also hide the recovery data inside the keyrings, and obfuscate
them to hell and back around the file system in slack space etc.  This
is to make it harder to copy to a floppy.

So now the GAKkers can still get your recovery info, because they
could theoretically unwind that problem.  But it is sure a lot harder
than requiring every one to email them a copy of the key they just put
on a disk.  The software doesn't give you any help obtaining your key
in a mailable form, or in a form to stick on a floppy either.  In fact
it does it's damnest to prevent it.

This is the kind of monkey-wrenching PGP should be investigating,
rather than investing time in designing `elegant' GAK implementations.

Combine with forward secrecy with as quick update time as you can
manage without interfering with ergonomics issues, and the GAKkers
have got to come back every 5 minutes, and grab a copy of your entire
disk, or reverse engineer the obfuscation, to grab the next obfuscated
key.

> [Sidetrack: which is of course why PGP had to find another solution to
> present to those customers already using GAK. IMHO, and I can't help but
> be a bit surprised that I find myself in the minority on this
> issue, at least as far as the list is concerned. What PGP did was
> _elegant_.]

Wow, Lucky! I usually consider you to be spot on most such things, but
I think you failed to hit the bulls-eye there; in fact I think you
missed the dartboard entirely!

I thought it was you who was pointing out earlier the fallacy induced
by the key escrow meme (escrowing transient communicatoins keys with
governments or companies to recover data stored on frigging disks!)
(Actually you applied it just to goverments but the argument extends
to companies perfectly).

The only way that it's elegant is that it is an elegant fully ready to
roll GAK implementation.

(Notice Bruce Schneier's forward of a case of a GAKker already
starting to crow about the demonstration of GAKware feasibility in
PGP).

There are plenty of less GAK compliant things you can do than what
they are doing.  The anti-GAK design principles help to clarify
thought in designing a full spectrum from mildly GAK resistant through
to rabidly GAK-hostile.  I would hope that PGP (and you lot at C2Net)
will crank the setting up to mad dog rabid anti GAK mode with nested
obfuscated interpreters interpreting each other interpreting
instruction sequences to recover keys.  And busting your butts to make
your systems ergonomic and slick to the extent that the competitors
GAKware products look like dried up turds in comparison.  Deployment
being probably the most important anti-GAK principle of all!

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`