1995-01-14 - Re: How do I know if its encrypted?

Header Data

From: jpb@gate.net
To: cypherpunks@toad.com (cypherpunks mailing list)
Message Hash: 43b865475c04848fca64e31b0944c3ea429cf48a215dc982d7fa13c4b81fa504
Message ID: <199501140437.XAA14922@hopi.gate.net>
Reply To: N/A
UTC Datetime: 1995-01-14 04:38:20 UTC
Raw Date: Fri, 13 Jan 95 20:38:20 PST

Raw message

From: jpb@gate.net
Date: Fri, 13 Jan 95 20:38:20 PST
To: cypherpunks@toad.com (cypherpunks mailing list)
Subject: Re: How do I know if its encrypted?
Message-ID: <199501140437.XAA14922@hopi.gate.net>
MIME-Version: 1.0
Content-Type: text


I accidentally sent a reply to Ben's letter solely to him.  He responds here
to the major points I brought up.  I'm forwarding it here with his permission.

Ben's text begins

At 8:11 AM 1/13/95, jpb@gate.net wrote:
>Ben.Goren@asu.edu said
>> Here's a solution:
>>
>> Alice sends a file to Dave's DataHaven. When Alice wants her file back, she
>> sends to Dave a secure hash of the file, a key with which to decrypt it,
>> and a handful of plaintext at the beginning of the file. Dave decrypts the
>> file that matches the hash with the key Alice gave him; if the file begins
>> as Alice says it should, Dave returns the file to Alice.
>
>If Alice initially encrypts the file to herself, and then encrypts it to Dave
>(Dave doesn't accept non-encrypted files), Dave doesn't need to decrypt it.
>If Dave even *can* decrypt it, and makes a policy of decryption, he is
>setting himself up for legal liability.
>
>Dave should allow anyone who can provide the MD5 of the cyphertext, the
>fileid and the fee to retrieve the file.  Retrieval requests will of course
>also require a pgp key to encrypt the file to and a anonymous remailer block.

I address this somewhat further in a response to Eric Hughes on the list.
Basically, Dave wants to make sure that he can't see what's in the file. My
scheme guarantees that the file is unreadable to anybody but the owner
until the owner asks for it back. If return of the file is automated,
Dave'll never know what's in it. Alice should, of course, further protect
her data if she feels the need.

>> This way, only those people who have an intimate knowledge of the files can
>> recover them.
>
>I agree that this is a good thing to enforce.
>
>> Dave can have a policy whereby he deletes a file after returning it, unless
>> Alice pays more to keep it there. Thus, Bad Bobby can send his naughty
>> pictures to Dave, tell the 'net how to get them--but the first person who
>> neglects to include the fee to leave the pictures there winds up blocking
>> out everybody else. Similarly, Samaritan Sam could get into a spending war
>> with Bobby. Each time Bobby sends Dave his smut, Sam retrieves the file
>> without paying for its continued storage--and takes a sneak peak at the
>> pictures before deleting them himself.
>
>This is a bad policy for Dave from a financial point of view.  If Alice pays
>for a 30 day storage, it should stay there for 30 days.  This means that Dave
>also needs to require an owner-password when the file is initially stored,
>but that is no big deal.

Change the payment structure a little and you don't have those worries.
Alice doesn't pay for thirty day storage, but rather pays for at least
thirty day storage. If she thinks she'll be getting the file back in
fifteen days, she only pays for that long. If she needs it for longer than
that, she sends another payment before the file expires.

>In a perfect world, Alice could specify an extra retrieval charge over and
>above Dave's, and the DH would enforce this and pass the extra money on to
>Alice.  This would allow for information sale when neither party trusts the
>other - Alice and Bob can agree on a fee for the file through anonymous means,
>and once it is set, Bob can send in the cash and be sure the file will be
>sent.

That's the job of a data broker, not a data haven. Dave might well wish to
offer that service, too, but, if I were him, I'd keep the two obviously
separate.

>Whether or not the file is what it is advertised to be is a whole
>new problem that can't be solved securely in software.

Not without an awfully good AI....





Thread