[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [freehaven-dev] Deletion of documents





Let's see :

* Before an "unpublishing event", the value of x must be kept by someone. 
  This person can then be linked to the document. Once he is linked to
  the document, he may be forced to unpublish the document. 

  This is a significant concern. 

* "During" an unpublishing event, if an adversary can trace a message
   announcing x to its original sender, then this associates the sender
   and the document. This means that we're trusting the anonymous
   channel again.  

* After an unpublishing event, the value of x can be destroyed, removing
  the link between the holder of x and the document. So if the event 
  itself is carried out in an anonymous fashion, no adversary can
  later link the unpublished document to anyone. 

* It gives share creator the option whether or not to include the
  ability to unpublish. That is, instead of picking a known x and
  setting y = SHA1(x), the share creator could set y to a random
  bit string (or hash a random x and immediately destroy x). Now
  unpublishing requires finding a target collision in SHA1.

  There doesn't seem to be any nice way to show that a share really 
  is "unpublishable" -- since even if you require a proof of the 
  pre-image of y (Hal Finney has done some *implementation* of this),
  nothing stops the share creator from forgetting x after providing the
  proof. 

So far, it seems we could have acheived the same functionality by allowing
unpublish requests signed by the private key used to sign shares.
Immediately after sending the command to unpublish, the key holder 
eradicates the share private key - which is the same thing as destroying x
in this scheme. 

Notice that in both cases, once the secret is destroyed, the unpublisher
and the document can't be linked. 

This scheme seems different from the "unpublish signed by same private key
as signed shares" in these respects :

* Efficiency --

Hashing is much more efficient than most signature
verification. well, unless we're using merkle's hash tree sigs or
something. (hey, would that be a possible optimization, since we already
have expire times? the signature is only good one million times or so,
then the share and sig expire?)

* Divorce unpublishing from publishing -- 

  Whoever enters the shares into the servnet and signs them with whatever
  key does not need to know x. She just needs to know y = SHA1(x). So she
  does not necessarily have the ability to unpublish - someone else may. 

  That someone else who knows x, in turn, doesn't necessarily have any 
  knowledge or control over which shares can be unpublished by revealing 
  the value of x. 

  So this means I can "delegate" or "escrow" the ability to unpublish 
  data by including y values generated by somebody else. You might be
  able to do this in the "unpublish signed by private key" model, but
  it seems to require key escrow and will be messier.

  For example, suppose Alice wants to publish a dissident tract in
  China. She might want to unpublish or edit it later. So she could use a
  y-value provided by Amnesty International, or some other third party she
  trusts not to act in the interests of the Chinese State. 

  It's probably important that Alice choose a y value from a party 
  which she cannot control or command to release x. Otherwise in the 
  above example, the Chinese state tortures Alice until she tells
  Amnesty International to reveal x.  
 
  A much less appealing example is the case in which an agency of the 
  State publishes lists of y values. Shares residing on freehaven 
  servers under that state's jurisdiction are then legally required to
  incorporate one of these y values as their self destruct code. Failure
  to do so is made grounds for seizing the server (you think I'm 
  exaggerating - look at money laundering laws in the U.S.). 

There may be more on the "separation of publishing and unpublishing"
point, but I think this shows some applications. It seems to be a
partial way around the "forced unpublishing by coercion" problem, but
also has the potential for nastiness (mandated escrowed unpublishing). 

I can't think of other distinctions between this and "unpublish requests
signed by key" right now. Please let me know if I missed anything.

Thanks, 
-David Molnar

On Sat, 11 Mar 2000, Ron Rivest wrote:

> 
> Why not just publish a value y=SHA1(x) with a document.  y could exist
> with each share.  When x is revealed, anyone holding a share with
> "self-destruct code" y should delete their share...
> 
> 	Cheers,
> 	Ron
>