[freehaven-dev] Unpublishing redux

[dmolnar@belegost.mit.edu]

On Wed, 15 Mar 2000, Brett Wooldridge wrote:
> The lack of ability to revoke a publication could be as much a threat to the
> user as the other side of the coin -- the danger of keeping revocation keys.
> From my perspective, the ability of an author to revoke a document borders
> on a "right".

Last night I ran into Roger and Rivest. They told me that Rivest had
suggested the following :
	
	* Give share creators a choice as to whether a share can be 
	unpublished or not. Then make it obvious from inspection 
	whether a share can be unpublished or not. For instance,
	if we use a "self destruct code", then the presence of
	such a code in the share means that the share can be unpublished.

	If the code does not exist, then the share can only be removed
	by expiring, or by finding all copies and manually destroying
	them. The choice of what kind of share we have is made at
	dispersal time. 

This is a neat idea, since it offers the choice as to what kind of
system we are willing to have. 

How about we call shares which can be unpublished "unpublishable"
and shares which cannot be easily unpublished "persistent" ?
(If there's already terms floating around, please correct me)

A few things I came up with to look at :

* Framing	

	We have said that we want persistent shares in order to make
	"beat the unpublishing key out of him" attacks useless. The idea
	seems to be that if the adversary knows beating you will not 
	allow him to unpublish data, then he will eventually stop
	beating you. 

  What happens if someone pulls out a file consisting of persistent
  shares, reconstructs it, and then enters an unpublishable version?
 
 Can one adversary be fooled into thinking you have the ability to
  unpublish this copy of the file? Will the adversary care about
  removing the unpublishable copy if there is also a persistent copy
  lying around (will the adversary know of the existence of both 
  copies?)

  I'm worried about the situation where someone enters a copy of your
  file which looks unpublishable, but really isn't. At least not by
  you. Then the beating begins. 


* Convertible shares. 
 
  Have a duress procedure which somehow changes an unpublishable share
  into a persistent share. This saves space and time over entering 
  the file into freehaven again as persistent shares. In addition, we
  would want that the conversion be independent of the file, and so could
  be carried out by anyone. 
  
  The naive way of doing this is to simply broadcast a command not to
  honor unpublish requests. This requires keeping extra state. Better
  would be something which could change the share such that it still
  validates, but no longer has whatever attribute allows it to be 
  unpublished.

  For example, we could have the self-destruct code in a separate signd
  string from the rest of the share - i.e. not
	
    share =	SIGN(destruct, convert, description, restofshare) 
but 
    share  =	SIGN(destruct, convert), SIGN(description, restofshare)

  and then servers check incoming commands to see if convert is correct,
  then if so delete the SIGN(destruct, convert) to convert? 

  The above has the annoying property that the SIGN(destruct, convert)
  could be replaced by a different SIGN'(destruct', convert') from 
  someone else. This would be certainly be caught by checking that the two
  parts of the share are signed by the same key, but it looks like an
  extra sig verification. :-/


  By the way, conversion should always be from unpublishable to  
  persistent. It makes no sense to convert from persistent to 
  unpublishable, because then that share wasn't really persistent,
  was it? 

  Since conversion from unpublishable to persistent is not what an
  adversary wants, the adversary will not beat you in order to discover
  your convert code. On the other hand, the adversary may beat you 
  to prevent you from using the convert code, or perhaps for
  retribution after you use a convert code. 

* Delegation of conversion.
 
  This makes more sense than delegation of unpublishing. Now the Chinese
  dissident can use Amnesty International to ensure his shares stay
  around, even if he's being tortured. 


Thanks, 
-David