From: Eli Brandt <eli@gs160.sp.cs.cmu.edu>
Date: Fri, 17 Oct 1997 06:37:51 +0800
To: cypherpunks@toad.com
Subject: Re: FCPUNX:proposal: commercial data recovery
In-Reply-To: <199710161410.KAA29078@beast.brainlink.com>
Message-ID: <199710162154.OAA01432@toad.com>
MIME-Version: 1.0
Content-Type: text/plain



Will Price wrote:
> In your model, the recipient automatically
> decrypts and then re-encrypts to a data recovery key -- even though
> end-user computers are likely to be insecure thus making this decrypt &
> reencrypt step rather specious at best.

The value of this security model escapes me -- if the receiver's
machine is insecure, you lose, period.  Please, let us assume that
neither endpoint is controlled by an attacker.

You are concerned that the recipient is re-encrypting with a key whose
access characteristics are unknown to the sender.  Now, for all the
sender really knows, the recipient may be storing the message in the
clear, or maybe putting it on a Times Square billboard.

This is not a cryptographic failure.  In your CMR system as well, the
sender has no choice but to trust the recipient's integrity and data
hygeine -- or to not send the message.  The headers could contain a
request as to the eventual disposition of the message, but there are
never any guarantees.

> As an actual data recovery system, it also fails fundamental tests.  If I
> encrypt critical data to a colleague wiping it from my system after
> sending, then the colleague is incapacitated before receipt and processing
> of the message, the data can never be retrieved.  

Forget bus-struck colleagues, think unreliable messaging -- if you do
this and your e-mail is lost in transit, your "critical data" is lost.
So don't do this.

> A data recovery system
> must solve this kind of issue -- data recovery here means that from
> end-to-end the data is recoverable in case of emergency.  One cannot ignore
> message transit time in this -- it can take days for a message to travel
> from AOL to the outside world.

I'm not seeing how transit time figures in here.  Are you proposing to
bypass it by sending in an emergency team to acquire the in-transit
message from the AOL machine room?  If you find this practical, you can
even retrieve an un-CMRed message by putting the recipient on this
emergency team.  But as I said, this situation should never be allowed
to arise.

Data recovery means you can get the data.  It doesn't specify which copy
you get decrypt.  For reliable transmission over an unreliable medium,
the sender must not destroy the original until receipt has been
confirmed; for stored-data recovery, "receipt" involves appropriate
re-encryption.  (A reliable medium simply involves shoving all of this
down into the messaging protocol.)  So reliable transmission can support
data recovery, from one end or the other, without message recovery.

You might ask what happens if both endpoints are struck by meteorites.
If the data is critically important, it will have been replicated off
the sender's disk.  The bottom line is that no such data can be trusted
solely to an AOL mailserver (of all things).

> If you don't need data recovery, don't use
> it, but at least respect the people who do need it and need it to actually
> work at all points.

I'm no protocol designer, but I'd have more respect for this system if
explanations for its necessity seemed to have been fully thought through.
The issue of communications keys versus storage keys has been discussed
before; I don't believe I'm raising any novel issues.  Did PGP Inc.
consider and reject stored-data recovery (if so, what were the good
reasons?), or are we seeing a retroactive explanation here?

-- 
     Eli Brandt  |  eli+@cs.cmu.edu  |  http://www.cs.cmu.edu/~eli/
     (on FCPUNX, cc'ed replies appreciated)