How to eliminate liability?

This is just an idea I thought I would throw out and see what happens.  
There has been considerable discussion recently about datahavens, how no 
one physical location in meatspace is safe, and how there is no single 
place on earth that a datahaven could exist that would accept all kinds 
of information.

Well, what about spreading the information out?  Something simple like 
doing a matrix rotation on the scrambled data in 8 byte blocks and 
splice it by bit to split the data up, add ECC (error correction code) 
to it, and spread it to several servers.  This way no one server has all 
the information necessary to recreate the "offending" information and if 
one server gets "hit" (killed), the information can still be regenerated 
from the the information and ECC from the other servers.

The bit splitting I'm talking about would go something like this.  The 
data would be set up in clusters of eight bytes and then these eight 
bytes would be rotated, error correction applied, divided byte by byte 
to separate queues (for separate destinations), resequenced to include 
the ECC overhead, and sent on it's merry way.

Original encrypted information:

Cluster A               Cluster B...
Byte 1: 01001011
Byte 2: 10101110
Byte 3: 10010110
Byte 4: 10110111
Byte 5: 01011100
Byte 6: 10111011
Byte 7: 10001101
Byte 8: 00110110

After the matrix rotate:

Cluster A               Cluster B...
Byte 1: 01110110
Byte 2: 10001000
Byte 3: 01010101
Byte 4: 00111101
Byte 5: 11001110
Byte 6: 01111011
Byte 7: 11110101
Byte 8: 10010110


Add ECC:

Cluster A               Cluster B...
Byte 1:   01110110 1
Byte 2:   10001000 0
Byte 3:   01010101 0
Byte 4:   00111101 1
Byte 5:   11001110 1
Byte 6:   01111011 0
Byte 7:   11110101 0
Byte 8:   10010110 0

ECC byte: 01000000 0


Divided up:

Cluster A         ECC-A  Cluster B ECC-B
Byte 1: 01110110  1      10100011  0

Resequenced into separate queues by byte in cluster:

01110110 11010001 10......

...and distributed to the servers.


These are just my ramblings, I'm not a programmer (or at least I haven't 
been for a long time).  Nor do I claim to know if this form of 
distribution will escape the legal issues of storing certain data on on 
servers in specific areas of meatspace (I'm no lawyer (kill the 
lawyers)).  At the very least, it seems that this scheme (or something 
like it, if this form of ECC is not sufficient) could be used to keep 
data from being lost if one or more servers gets whacked by armed forces 
or a nuclear bomb.  I'm not even going to think about how this data 
could be distributed.  You guys can do that...

Feedback and flames welcome.

John

estoy@hotmail.com



______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com

At 09:23 PM 1/22/98 PST, John M wrote:
>There has been considerable discussion recently about datahavens, how no 
>one physical location in meatspace is safe, and how there is no single 
>place on earth that a datahaven could exist that would accept all kinds 
>of information.
>Well, what about spreading the information out?  Something simple like 
> [...] and spread it to several servers.  This way no one server has all 
>the information necessary to recreate the "offending" information and if 
>one server gets "hit" (killed), the information can still be regenerated 
>from the the information and ECC from the other servers.

Secret Sharing is easy, and there are a number of implementations with
useful properties like being able to read the original from K of N parts.*
The problem is how to implement it in ways that protect the server
operators as well as the information providers.  For instance,
the author's client software can do the split and send the shares too
different servers, and make sure the readers know how to find the pieces;
this can even be automated enough to make it convenient.
This not only makes it hard for the Bad Guys to find the pieces,
it makes it impossible for the data haven provider to know what's
being stored there, and even if the site is siezed it doesn't give up
the critical information.  This is a Good Thing, and we've discussed it.

On the other hand, what happens if a Bad Guy wants to entrap the operator,
by planting child pornography, pirated software, and TOP SECRET data
in the data haven, advertising on Usenet and then calling the cops.  
Anybody, including the cops, can retrieve the contraband and bust them.
So what are the alternatives, besides obviously encrypting your disks
so it's harder to determine what's on them besides the plant,
and the ever popular "don't let them find your physical location"?
Perhaps the data haven can do the split and farm the data out to
other data havens - but how do they know the data they're receiving
is really a slice of contraband data instead of Yet Another Plant?
It gets pretty convoluted.

[* You can read about secret sharing in Schneier. ]
				Thanks! 
					Bill
Bill Stewart, bill.stewart@pobox.com
PGP Fingerprint D454 E202 CBC8 40BF  3C85 B884 0ABE 4639

John M wrote:

> Well, what about spreading the information out?  Something simple like
> doing a matrix rotation on the scrambled data in 8 byte blocks and
> splice it by bit to split the data up, add ECC (error correction code)
> to it, and spread it to several servers.  This way no one server has all
> the information necessary to recreate the "offending" information and if
> one server gets "hit" (killed), the information can still be regenerated
> from the the information and ECC from the other servers.


This seems like another variation of the 'reverse secret-sharing' schemes,
independently proposed by Jim McCoy, Matt Ghio, and others.

Cooper and Birman give a good theoretical introduction at
http://cs-tr.cs.cornell.edu/TR/CORNELLCS:TR95-1490
although their scheme uses only the simple XOR instead of a full matrix.

Ghio's version is at
http://infinity.nus.sg/cypherpunks/dir.archive-97.06.12-97.06.18/0391.html

Neither paper goes heavily into linear algebra, but the scheme can easily
be extended to martices in a finite field, xor being the special case of
mod 2.

The idea's been around for awhile; it'd be nice to see a working
implementation (hint, hint).