From: Black Unicorn <unicorn@access.digex.net>
Date: Tue, 17 Jan 95 12:49:59 PST
To: wcs@anchor.ho.att.com
Subject: Re: Another problem w/Data Havens...
In-Reply-To: <9501170829.AA10034@anchor.ho.att.com>
Message-ID: <Pine.SUN.3.91.950117154344.11572B-100000@access4.digex.net>
MIME-Version: 1.0
Content-Type: text/plain


On Tue, 17 Jan 1995 wcs@anchor.ho.att.com wrote:

> Date: Tue, 17 Jan 95 03:29:17 EST
> From: wcs@anchor.ho.att.com
> To: grendel@netaxs.com
> Cc: cypherpunks@toad.com
> Subject: Re: Another problem w/Data Havens...
> 
> 
> Liability is a legal issue, not a technical one.
> (Catchability is a technical issue.)

BING!

> 
> 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.

I found this very insightful.  All the more reason to mandate encryption, 
or to encrypt all plaintext on arrival.

> 
> 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.

I like the pure elegance of this solution.
Are there implemented DH codes running around anywhere?

> 
> 
> 			Bill
> 			
> "Privacy is not a crime!"			
> 

073BB885A786F666 nemo repente fuit turpissimus - potestas scientiae in usu est
6E6D4506F6EDBC17 quaere verum ad infinitum, loquitur sub rosa    -    wichtig!