Skip to Content.
Sympa Menu

bluesky - Re: "hot potato" sub-protocol for plausible deniability (Re: User Anonymity)

bluesky AT lists.ibiblio.org

Subject: Global-Scale Distributed Storage Systems

List archive

Chronological Thread  
  • From: Adam Back <adam AT cypherspace.org>
  • To: weidai AT eskimo.com
  • Cc: bluesky AT franklin.oit.unc.edu
  • Subject: Re: "hot potato" sub-protocol for plausible deniability (Re: User Anonymity)
  • Date: Fri, 16 Feb 2001 08:39:17 -0500



> On Fri, Feb 16, 2001 at 01:01:27AM -0500, Adam Back wrote:
> > So here's a simple though probably quite inefficient algorithm to
> > have plausible deniability. Each node answers a request just once,
> > then it deletes the content. Now if the attacker discovers some
> > content, the server operator running unmodified software can quite
> > reasonably claim he did not know his server carried that content.
> > If he had used the browsing software to obtain the content, the
> > server would by definition not have the content.
>
> I don't think that really accomplishes plausible deniability. I
> think the criteria for it should be:
>
> 1. The server has no way of knowing that it is storing or transporting
> a banned object or part of a banned object.
>
> 2. There is a plausible reason why it can not know; it can't just be
> the result of a mechanism designed solely to avoid this knowledge.
>
> Without (1), the authorities can impose censorship duty on all servers
> and punish those that don't comply. Without (2), the authorities can
> ban usage of the special "ignorance" mechanism.

You are right with (1). I was restating a much earlier discussion,
which had context I omitted.

The context was the content is encrypted so that the server can't read
it. The document key is also encrypted so the server can't read it.

A simple scheme is the one I used in USENET Eternity: both the URL and
the document key are derived from the human readable URL with a Key
Derivation Function. In this way the only way for the server to
discover what it has is to find all eternity URLs and brute force to
discover which ones it has. With the addition that the server only
serves each file once, this means that absent software modification,
or digging in internals the server wouldn't no longer have a block
even if it found something using the browsing interface.

I added a (3) which has different aims than pluasible deniability:

(3) Once an attacker has discovered the server could have served that
block, he has destroyed it's ability to further serve the block,
and is fairly confident that it never served the block to anyone
other than the attacker.

I'm thinking that this will make it difficult to prosecute: he didn't
serve the block to other people, plus (1) that he didn't know what he
was serving.

I'm less sure about (2) here you want the purpose of the design
construct to have pluasible other purposes than reducing liability.
This seems like an odd mix of legal interpretations and design
criteria.

I also had in mind (4) which was also unstated:

(4) The document lookup key should change each time it moves.

This makes it very hard to find things, and means you need a
distributed name resolution service which is rapidly updated.

So this defers the censor ship problem (if you expect all these
plausible deniability tricks to hold up in a court) to the distributed
name resolution service. The attacker will try to remove the name
which is after all static. But a name you would think is less
controversial to host, as it's not the data, it's a pointer to the
data. Internic typically doesn't get in trouble when a site hosts
controversial data. Then again people linking to URLs have been told
to remove URLs.

However courts have no sense of fair play it seems; ultimately they
could just declare the whole thing a RICO conspiracy or something and
seize equipment in a draconian way until people are scared off. But
I'm not sure such draconian measures are politically achievable.
People post all sorts of content on USENET, and there are fights about
it but USENET lives.

Adam




Archive powered by MHonArc 2.6.24.

Top of Page