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

Re: [freehaven-dev] Deletion of documents

On Sat, 11 Mar 2000, Michael J. Freedman wrote:
> >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. 
> I disagree.  A signature gives some knowledge of the publisher.  Even if we
> don't have the PK of the signer  (publisher) listed in the file, it is

It seems to me that you're considering a case in which the publisher signs
shares of a file with "his own" key, which is different from what I had
in mind. Here is what I mean in detail -

We have previously considered a situation in which a new public and 
private key pair is created for each file entered into the servnet. 
Each share of the file is signed by this private key and the shares
entered into the servnet. 

Then in order to reconstruct, we first obtain the public key of the 
file we want. Either we look it up in a directory, or perhaps we can
somehow build the public key such that the key *is* a description of the
file. Then we send a request for all shares signed by that key. 

In some sense, the file has an "identity" defined by this signing key. 
Since we make new key pairs for each and every file, the identity is
very restricted in scope. In particular, it doesn't need to be associated
with any reply blocks or other mix-net persistent ID of any kind. 

Previously, we had considered the case where the private signing key is
destroyed as soon as the file is entered into the servnet. This protects
the publisher, since it destroys the link between him and the file's

We could extend our scheme to allow unpublishing by having servers honor
requests to unpublish signed with the same private key as a share. Now it
seems that the private key must be kept around -- or at least unpublishing
requests signed by the private key -- until unpublishing time.

I did *not* mean to say that unpublishing requests would be signed by
the private key associated with the actual publishing party. Your comment
about "brute-force checking of PK" to see which party signed something
suggests that this is what I got across. My apologies. 

Instead, the private key is kept truly private and never at all associated
with the publisher. The problem is that now the publisher must keep
the private key for as long as he wants the option of unpublishing. This
means that if the publisher is raided for some other reason, and the key
is found, then he can be linked to a file and then forced to unpublish it
and go to jail. 

Have I understood what you were getting at?