From: wcs@anchor.ho.att.com (bill.stewart@pleasantonca.ncr.com +1-510-484-6204)
Date: Tue, 17 Jan 95 00:32:34 PST
To: grendel@netaxs.com
Subject: Re: Another problem w/Data Havens...
Message-ID: <9501170829.AA10034@anchor.ho.att.com>
MIME-Version: 1.0
Content-Type: text/plain


Michael wrote:
> 	This entire discussion is completely unnecessary. There are ways 
> of removing operator liability without examining the submission at all.

Liability is a legal issue, not a technical one.
(Catchability is a technical issue.)
The basic ways to remove liability are to either run your system
where the local laws don't object to information storage,
or to reduce the operator's involvement to levels that the
local legal system will tolerate.  The former case is easy,
if you can rent computer space in a country with a non-meddling
government and good net access (or an easily rentable government :-).)
For those of us in the latter situation, the discussion's still
useful...

On Mon, 16 Jan 1995, Johnathan Corgan wrote:
> > It just occurred to me when reading this another method for ensuring
> > the "I can't tell what's in it" condition with a data haven operator.
> > Why not use a secret sharing system where the contraband data is 
> > split into a number of pieces and sent to different havens?

Good, but still has most of the same old risks.

Alice asks Dave's Data Haven to store stuff, and later retrieves it.
Dave doesn't want to be able to know what's in it.
There are three main threat periods - at receipt of the data,
during storage, and at retrieval.  Secret sharing is great for
the storage period, assuming the data havens are in different
jurisdictions and the cops can't force the operator (Dave)
to go retrieve all the pieces.  

However, at receipt of the data, it's all in one place, Dave's inbox.
If Alice encrypted it safely, or secret-shared it herself, great!
But if Alice is a narc trying to entrap Dave with plaintext ThoughtCrime,
or Alice's key has been compromised, anything in Dave's inbox is
still toast, even if anything that's been split and stored is safer
than if it had been stored unsplit.  So he either needs to split it fast,
shortening the window, or find a way to blind his mail before processing it,
or split it before reading it.

Splitting before reading isn't impossible in a stream environment.
Define a protocol that looks like SMTP, but opens up three outgoing 
streams as well as an incoming stream, and uses standard mail formats.
While reading the headers from Alice (either the real contents or just the
handshakes at the beginning), Dave's receiver thinks about them
and sends some meaningful headers to Moe, Larry, and Curly.
Once the message body starts, instead of storing the incoming bytes,
Dave sends every other byte to Moe or Larry, and the xors to Curly.*
If he wants to get fancy, he can even encrypt the data with a stream
cypher as he goes along, giving half the key to each of them.
That way, Dave's system really only has knowledge of the headers,
plus one line at a time of incriminating data on the fly.
And his partners can't give anything away either; they're just stooges.

* If the connections to and storage by Moe and Larry are reliable enough,
Curly doesn't really need to be involved, but the xor business lets
you reconstruct everything from just two parts.


			Bill
			
"Privacy is not a crime!"