Skip to Content.
Sympa Menu

bluesky - "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: "hot potato" sub-protocol for plausible deniability (Re: User Anonymity)
  • Date: Fri, 16 Feb 2001 01:01:27 -0500



Wei also wrote:
> Let's talk about how to reduce the penalties (for example through
> plausible deniability) or the probability of getting caught. To be
> concrete, let me propose an enforcement mechanism the authorities
> may use. A list of banned hashes is published. Any server found to
> be storing or transporting any object that hashes to an entry in the
> list will be confiscated.
>
> Now the enforcers periodicly request items on the list, and
> confiscates any server that responds. This mechanism seems effective
> against any conceivable storage system, so perhaps if jurisdiction
> shopping can't do the job, nothing else can.

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.

Clearly you also need some mechanism to ensure distribution, otherwise
content just dies out quickly.

One way is to move the data around, like a hot potato, rather than
delete it, though this seems likely to be bandwidth inefficient.

Graydon proposes something related in his Symptomatic File System [1]:

| The motivating cases above are difficult to address primarily
| because any illigitimate user wishing to disrupt file service need
| only masquerade as a legitimate user long enough to locate the
| server with a file they dislike, and then commence an attack on that
| server (uniquely determined by IP address). SFS solves this scenario
| in an unorthodox way: rather than trying to resist attack, when a
| file server S even suspects it is under any form of attack it
| immediately falls over, dead as a doornail.
|
| [...]
|
| all file servers simply follow an algorithmic rule of thumb: In
| order for S to even begin providing file service for a given file
| named N, S must first secure a backup location somewhere along the
| hash chain for N, and only once the backup acknowledges that it has
| a copy can S begin to service requests.

Adam

[1] http://www.venge.net/graydon/SFS.html




Archive powered by MHonArc 2.6.24.

Top of Page