From: Adam Back <aba@dcs.ex.ac.uk>
To: kent@bywater.songbird.com
Message Hash: 240d6c90dc907ee60e5ce79ce862012a0768b6c3f9daf816882c9e3bf4466388
Message ID: <199710251055.LAA00694@server.test.net>
Reply To: <19971025002707.17636@bywater.songbird.com>
UTC Datetime: 1997-10-25 11:30:12 UTC
Raw Date: Sat, 25 Oct 1997 19:30:12 +0800
From: Adam Back <aba@dcs.ex.ac.uk>
Date: Sat, 25 Oct 1997 19:30:12 +0800
To: kent@bywater.songbird.com
Subject: Re: PGP, Inc.--What were they thinking?
In-Reply-To: <19971025002707.17636@bywater.songbird.com>
Message-ID: <199710251055.LAA00694@server.test.net>
MIME-Version: 1.0
Content-Type: text/plain
Kent Crispin <kent@bywater.songbird.com> writes:
> On Fri, Oct 24, 1997 at 02:42:19PM +0100, Adam Back wrote:
> > > It may be less obvious, but despite what PGP claims, a significant
> > > fraction of this demand is for the ability to SNOOP, and not just data
> > > recovery.
> >
> > Jon Callas <jon@pgp.com> writes:
> > : It is possible that
> > : there is an unstated perceived user requirement, that the messaging
> > : standard be able to allow third party access to the communications
> > : traffic directly.
> > :
> > : Nope, that's not what we're arguing for.
> >
> > So it would appear that your suspicious are unfounded...
>
> Jon's statement and my statement are consistent, if you look a little
> more closely.
Could you explain, please. I took it at face value. He made other
statements also denying that claim.
> > If this is the case, I reckon it's still better to just escrow their
> > comms keys locally.
>
> In my early days on the list I spent a great deal of effort arguing
> exactly this point, perhaps even with you. Perhaps you recall my
> discussions of the "key-safe" model. (I suppose we could check the
> archives...) At that time, however, my proposal was branded as key
> escrow and hence evil, and the STANDARD REPLY WAS THAT IT WOULD BE
> FAR, FAR BETTER TO JUST ENCRYPT TO A COMPANY KEY AS WELL AS THE
> PRIVATE KEY. *You* may even have made such arguments.
I recall your key safe. I also recall that you suggested cypherpunks
work out ways to do data recovery -- a suggestion which was ignored
because we figure why help them.
There are dangers with each. The company safe model is better, but
governments could come along and demand a copy of the keys in the
safe, if they are communications keys.
For this reason generally I reckon it's safer to stick only storage
keys in the safe. Don't back up comms keys.
There are some short-falls to not being able to recover comms keys
(like losing messages which were in transit at time of memory lapse).
So if you do need to recover comms keys, it is I think a good idea to
implement PGP WoT autenticated TLS (I described how to do this in
another post, a reply to one of Jon Callas posts). This is another
easy thing to do. A few days hacking at most, everything is in place,
even SMTP agents.
Another thing to do is opportunistic PFS. Use PFS when you can. This
just means sending a EG key with each message. If there is a reply,
the person replying uses the EG key. The recipient deletes the key
after use. (EG keys are cheap to generate, if you keep the same
public vales.) This is good because it allows the company recovery of
comms keys, but denys attackers (industrial espionage, rogue
government agents) access to the ciphertext.
All simple easy things to do.
> Now that PGP has actually gone and implemented exactly what some
> months ago was the preferred alternative, the jack-rabbit meme-ridden
> collective cypherpunk semiconciousness awakens from its hazy stupor
> and says "Huh! GAK!", and parades Key Escrow as a safer solution.
>
> So, for sure, either the thinking those months ago was shallow, or the
> thinking now is shallow. The third alternative, that the thinking has
> remained at a constant level, is interesting to contemplate.
Don't know which, but I do suspect a concrete example has helped to
clarify thought. Also CMR is a new development, yes people have
talked about multiple recipients before; but building in MTA support
to reject messages is an additional part of the system. (Clipper did
something similar rejection of non "recoverable" messages -- the 16
bit checksum with undisclosed checksum algorithm being one other
example).
> Yes, I did mention the matters of history, backward compatibility,
> and expedience under tight schedules as important factors.
I'm not sure it's _that_ valid, and heres a few reasons why: pgp5.0
has most of the CMR functionality in it -- this implies that PGP Inc
have been planning the CMR approach for ages. Also CDR, just
escrowing storage keys, is simple. Even simpler than CMR and mail
bouncing SMTP agents.
> The argument that leaking company secrets is the primary concern is
> fallacious for exactly the reason you mention -- there are a
> thousand ways to leak data out.
>
> There are other, more realistic concerns. Is the employee exchanging
> encoded gif images with his friends? Is the employee telling the truth
> about an exchange with a customer? Is the employee spending all his
> time reading mailing lists devoted to home-brew-beer, and other
> hobbies? Is the employee distributing porno images from an ftp site on
> a company computer? Is the employee running a consulting business on
> the company computers? For investigating any such suspicions,
> snooping incoming mail would be just as valuable as snooping outgoing
> mail.
>
> BTW: You may laugh -- But I have seen real-life instances of each of
> these examples.
I'm not laughing.
Protecting secrets stored on company machines is I suspect difficult.
This is because the company controls the machines: it owns them, it
probably installed the software, it can install more software when
you're not in the office (eg key board sniffer).
Also a sense of proportionality is useful; balance what can be weakly
enforced by software, against other ways that company NDAs can be
broken (frisbeeing DAT tape out of window), or other ways that
outsiders can send you info which the company wouldn't like (eg like
sending to your home email address).
> > Maybe. If PGP Inc want to go this far, and design software with these
> > features, I reckon local key escrow is better.
>
> I reckon local key escrow is better, myself. But be real for a
> moment, Adam.
Always try to be realistic, Kent.
> If they had designed a system with "local key escrow"
> they would have been crucified by the butterfly brains on cypherpunks
> far more intently than they are being lambasted for CMR.
Not quite as much I don't think. Especially if they had just
implemented storage key escrow. We've been discussing CKE (Commercial
Key Escrow) being fine and useful for ages, and GACK of messaging keys
being evil. This is a very old meme.
> The very phrase "KEY ESCROW IN PGP" would have turned the cypherpunk
> group mind into quivering jelly.
Would have got some opposition to be sure. But I really think there
would have been much less fuss.
> > However that is not what they are saying.
>
> It doesn't matter what they are saying, really. They designed
> something with a set of constraints, one of which was the meme of
> antipathy to anything that could be termed "key escrow".
And pro-privacy seemed to be one of the design principles also.
Unfortunately the net effect is worse than what a privacy and
politically neutral individual would have come up with just security
objectives.
> I understand what Lucky meant when he said that PGP had pulled the
> greatest hack ever on corporate America. It's so good that you have
> to conceal your mirth, for fear of screwing it up...
Please share what's so funny.
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`
Return to October 1997
Return to “Tim May <tcmay@got.net>”