1997-10-15 - Re: proposal: commercial data recovery

Header Data

From: Rick Smith <smith@securecomputing.com>
To: Adam Back <aba@dcs.ex.ac.uk>
Message Hash: 0c51cca849bce87aac9e024c509528edea0b0a4e678889ff7b3abeb3f741d607
Message ID: <v03007801b06aa6089ab9@[172.17.1.150]>
Reply To: <v03007804b0697514e0e4@[172.17.1.150]>
UTC Datetime: 1997-10-15 16:44:55 UTC
Raw Date: Thu, 16 Oct 1997 00:44:55 +0800

Raw message

From: Rick Smith <smith@securecomputing.com>
Date: Thu, 16 Oct 1997 00:44:55 +0800
To: Adam Back <aba@dcs.ex.ac.uk>
Subject: Re: proposal: commercial data recovery
In-Reply-To: <v03007804b0697514e0e4@[172.17.1.150]>
Message-ID: <v03007801b06aa6089ab9@[172.17.1.150]>
MIME-Version: 1.0
Content-Type: text/plain



In response to some things I said about crypto and firewalls, Adam Back wrote:

>I'm not sure whether pgp5.5 has this ability to screen messages prior
>to reading, and also not sure whether it has the ability to snoop
>messages prior to sending built in.

It's not a feature of 5.5, it's a separate activity that relies on the
presence of a third party key. The actual inspection occurs at a security
choke point like a firewall. That way the tests are applied consistently
regardless of mistakes made by clients in software installation or
configuration.

You noted that it might in fact be possible to get the same result with a
more GAK resistant implementation, and I agree. For example, if the
principals all update their public keys fairly often, then there's no
relatively key that's easy to escrow. The practical version of forward
secrecy, as it were. I have no objection to that. As far as I can tell,
there's nothing intrinsic in the current PGP proposals to prevent such an
implementation.

Concerning your other examples, I agree that there are ways to trade off
between degrees of GAK sensitivity and various customer security
objectives. However, this whole discussion revolves around the fact that
people rely heavily on off the shelf solutions, and there aren't the right
tools to do everything you're suggesting. I'd like to see things in the
crypto marketplace be as flexible as possible. Just because a few provide
some features that could in theory be applied to GAK doesn't IMHO mean that
those will manage to prevail. A diverse marketplace of crypto devices is
essential for it to flourish -- one that gives every customer the flavor
they want. That way the general public will develop a working understanding
of it. And we'll all learn what really works and what doesn't.

Let's face it, crypto is at about the same stage as cars were when Henry
Ford started building them. We really know as much about how crypto will
change the future as he did about the effects of cars. We can't start
engineering in governors to restrict our speed, or be restricting our
designs to governor-proof transmissions.

I regret I'll have to bow out of this discussion because I'll be on travel
for a couple of weeks. Have fun everyone.

Rick.
smith@securecomputing.com           Secure Computing Corporation
"Internet Cryptography" now in bookstores http://www.visi.com/crypto/







Thread