[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] Unpublishing redux
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
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 :
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
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
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
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)
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,
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.