From: Adam Back <aba@dcs.ex.ac.uk>
Date: Wed, 15 Oct 1997 15:06: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.971015055251.18802C-100000@pakastelohi.cypherpunks.to>
Message-ID: <199710150633.HAA11426@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain




> > 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).
> 
> I can't help but see a difference between enforcing to encrypt to a
> default key and storing the user's key outright. IMHO, the former entails
> less potential for abuse.

Tim covered that pretty well.  Inconvience is significant.  If we can
redesign the protocols or backup procedure so that the GAKker must
modify software before GAK is even possible we have largely won.  If
we can accomplish subversion of the OpenPGP standard we may be on to a
winner too...  if PGP can't implement their beloved GAK functionality
without being a non-conforming application.

All it takes is for the standard not to accept the pgp5.5 CMR key
extension.  It really is too new and experimental to include says all.

Let's include it as a may says Callas.  No thanks says all, we don't
want any of it; too new too experimental.

If it comes to it, and I figured I could get away with it from a sales
perspective I would toss out encrypted email data recovery altogether
in preference to implementing GAK for the GAKkers.

Implementing GAK for GAKkers has similar immorality to blowing away
freedom fighters in foreign countries for sport -- it results in dead
freedom fighters, and dead thought criminals (say boo to some
governments, and they'll have your head on a platter within hours).

The effect is not quite as direct, but it is surely the effect.

Even for selfish reasons we don't want GAK for ourselves, and this
eventuality is far from impossible in our respective countries.

> > 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!
> 
> Amen to the latter. I honestly don't see what PGP could have done better
> and still achieved deployment in companies that keep copies of all
> employees keys *today*. 

Sure they could.  Just simply switching from CMR to CDR:

Store encryption key encrypted to a company recovery key on their
disk.  Or on a floppy in the safe even.

No enforced second recipient necessary.  Recovery of archived messages
possible.

Enforced second recipients are worse than straight forward escrow.

This kind of thing is better for the reasons Tim listed in his defense
of storing the keys in the safe on a floppy as opposed to second
recipient.


How about forward secrecy?  You could make it even less GAK friendly
if the keys only lasted for seconds.  Then what are you going to do?
Send a constant stream of keys to NSA HQ?  What if the software tried
it's hardest to not allow recovery or access to it's keys (it's hardly
likely to given the desire for forward secrecy).  So how can that be
perverted for GAK?

Does PGP investigate these?  Hell no!  They whinge: ergonomics, too
complicated, not possible, you are having a group halucination, you
don't understand software design.

Yeah, that's right ain't it, we're group hallucinating, and Schneier
-- bah they ain't listening to him -- he's just not understanding it
right.

> And yes, I think what PGP is doing is better than keeping copies of
> the keys of all employees. Anyway, I now have access to the entire
> PGP 5.5 system and will subject it to thorough analysis. Methinks
> many people arecurrently rendering opinions on a design they haven't
> even seen yet.

You could have a point there.  Could you investigate and let us know
what it does?

important questions which I think are unclear:

- does it provide message screening functionality (human reading mail
  prior to delivery in both directions?)

- is pgp5.0 able to generate GAK compliant keys (CMR keys)?

- how much control does the SNMP remote configuration provide in
  restricting user

- can you have multiple CMR keys attached to a public key (like one
  for your company and one for the NSA?)

> Certainly, the part of PGP's SMTP agent that prevents you from  screwing
> up by accidentaly sending sensitive email unencrypted stands a good chance
> of being installed at my site. [Can we all agree that this is a useful
> feature]? More than once, I failed to encrypt an email that I meant to
> encrypt.

That part is a truly excellent feature.  I do this myself manually,
the mechanism I use that I read offline and use linux, so my mail is
sitting in /usr/spool/mqueue waiting to go when the connectivity comes
up.  So I go check the files I care about prior to actually
connecting.

However that's not the controversial SMTP policy enforcer property.
PGP Inc employees described that it rejects mail which is not CAK
compliant.

> As for C2 and GAK: as Lucky Green, I speak _only_ for myself. And I can
> therefore say that if my employer was to imlement GAK, I would quit the
> day I found out about it. It isn't going to happen.

I wasn't suggesting C2 was GAK friendly.  I was attempting to suggest
that there are things you can do to be even more rabidly GAK-hostile
than you already are.  Think: monkey wrench GAKkers who might put this
product to a work in a GAK setup.  Make the product be awkward about
the types of functionalities which they will want, make it drag it's
feet, make it hide data which it doesn't want transmitted, make it
cease to function when servers aren't local (eg. local LAN servers,
make them refuse to work for IP#s not on the same sub domain).  Be
imaginative.

PGP are at very best GAK neutral.  It doesn't try hard to stop GAKkers
deriving use from it.  It tries somewhat to prevent users hacking
around it's GAK features.  It coincidentally (if you believe GAK
neutral design philosophy) happens to be pretty useable to the
GAKkers.  It implements a method for a company which doesn't turn on
the GAK feature to advertise that keys are read by company.  Yeah
nice, but big deal right?

Contrast with trying to do all you can to ensure the product can not
be used for GAK without a protocol modification, or without software
recall, or non-backwards compatible widely fielded international
standard rewrite.  They do not appear to have tried any of these.

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`