[freehaven-dev] (FWD) Re: Anonymizing system for IPTPS

[Roger Dingledine <arma@mit.edu>]

[Forwarded, because Andrei is not subscribed to the freehaven-dev list.]

----- Forwarded message from owner-freehaven-dev@freehaven.net -----

From: Andrei Serjantov <Andrei.Serjantov@cl.cam.ac.uk>
To: Michael J Freedman <mfreed@MIT.EDU>
Cc: Andrei.Serjantov@cl.cam.ac.uk, freehaven-dev@freehaven.net
Subject: Re: Anonymizing system for IPTPS 
Date: Tue, 19 Feb 2002 14:24:38 +0000

Michael,

> I recently read your paper "Anonymizing Censorship Resistant Systems"
> 
>   http://www.cl.cam.ac.uk/~aas23/Anon_p2p2.ps
> 
> for the upcoming peer-to-peer workshop at MIT.  It makes several
> interesting points.  I had some questions and thought I'd offer some
> comments....

First of all, thank you very much for reading and commenting and apologies for 
the late reply.

> My basic read seems to be that you are distributing content via a
> mix-net chain, one block at each link.  You further add one layer of
> indirection between publisher and storer.

That is correct. Making use of reply onions.

> I had these thoughts:
> 
> -- Resource Management (Trivial Flooding)
> 
> What's to stop:
> 
>   X inserts 100 Gig into the system.  
>   Storers store it.
>   No more space in the system.
> 
> You'll note that Free Haven and Tangler both try to make stories for
> this: Free Haven talks about trading shares precisely to add some
> fungible resource (disk space * time).  Tangler talks about tickets
> (allocated via out-of-bounds means.)

Yes. There is nothing to stop a method like that to be layered on top of this 
system as well (obviously not Free-Haven-like, though). This just happens not 
to be the problem I am considering in these 5 pages.

> -- Accountability
> 
> A storer agrees to store a file.  It drops the file.  
> 
> Pastry tries to make some assumptions about smart cards, but these
> make me quite uncomfortable.  In an open peer-to-peer system, anybody
> can join, thus pseudo-spoofing is a problem: a user creates X servers.
> Everytime they get a request they just drop it.  This cuts down on the
> fault-tolerance of your system.

Indeed. I was definitely not thinking about smart-cards. Later in your email 
you said that you were not very satisfied with your solutions to 
accountability and resource management. Neither was I, so I simply did not put 
a solution like that into the design. Again, maybe I need to, but this 5 page 
paper is too short to contain soemthing like that.

A general point raised by one of the referees is that maybe I am proposing a 
technique useful for achieving better anonymity properties, not a complete 
design of the system (yet).

> Now, it seems like you are trying to use PAST to load balance in case
> of normal (non-malicious) failure, but I don't really understand that:
> 
> -- Use of PAST
> 
> You mention that you build on top of something like PAST for efficient
> lookup, etc.  I wish we could have had these nice building tools when
> thinking about Free Haven  =)

Now's the time to use what the Distributed Systems community give us.

> PAST is giving you some nice replication, load-balancing,
> fault-tolerance.  At least, normal applications using PAST/Pastry
> would.  You allude to this in the 2nd to last paragraph in the
> dicussion, but don't describe at all how the use of PAST ties into the
> use of mixnet reply blocks.  

Indeed I do not. For lack of space mostly. 

So here we go: The forwarder can easily share reply-blocks with many others, 
this is not a problem. After all, they do not know who the reply blocks point 
to, so there is no information in them. So PAST-replicated notes can act as 
forwarders to provide extra fault-tolerance and attack-resistance. I think 
there is no problem with that.

The storers can be replicated as well -- the encrypted shares have little info 
in them as well. I don't think this gives rise to an attack either (do you 
think otherwise?)

Sorry, there is another slight complication (I cannot use v_i throughout, I 
need to use v_i at the forwarder and v_i' at the storer so the forwarder keeps 
the v_i -> v_i' correspondence), so my answers above are a lot more informal 
than they could be. Full details in the forthcoming final version.

> (These reply-blocks are very brittle --
> any break in the chain will cause the block to fail -- but anyway,
> that's another issue).  

That is indeed a problem, and one I thought originally I would solve by 
replicating private keys to very very few (1-2) neighbouring nodes. That was 
very naive -- I think I am now inclined to use an underlying mix network. 
Though there are other reasons for that as well.

> If we publish r_a, who knows r_s: 1. if a goes
> away, it's lost (nobody else can decrypt the onion) 2. if s goes away,
> it's lost.  I don't see how PAST helps?

Indeed. I hope the answers above clear this up.
 
> -- Minor: if you could give a table or something of variables it would
>    be helpful, I found myself looking back over several times to
>    figure out what everything meant.

I'll try to fit that in.
 
> -- Minor: the citation for Free Haven leaves out the third author, David
>    Molnar.  For simplicitly, I included several bibtex references
>    which may be useful below.

Apologies to David and thank you for the references.
 
> Quite a bit of the complexity (share trading, reputation) with Free
> Haven is that we were trying to handle these resource management and
> accountability issues, esp. focusing on promising long-term storage.
> The real reason we never implemented it was that we weren't convinced
> it would actually solve these problems, so we decided to wait until we
> believed them more.

Yes. As above, I was not conviced by these solutions either and left them out 
of the design. Though I am probably inclined to think that they are better 
than nothing.
 
> One of the arguments for entanglements for Tangler is actually the
> following: one reason a legal attacker could be target an mp3 tangled
> with the Declaration of Independence is that, in the US under the
> DMCA, they would have to swear, under penalty of perjury, that they
> own the rights to the object.  Obviously, they don't own the rights to
> the Declaration of Independence, so the legality is much trickier...

Ah, ok, none of us here in Cambridge here knew that. That's interesting.
 
> Anyway, I thought I should also mention that I'll be presenting at the
> workshop about Tarzan, which is a low-level anonymizing network for
> any IP traffic -- I'm connected via it right now :) I think it's
> something that many systems, like Free Haven, Tangler, or your's,
> might consider for all anonymous communication requestions.

Great! I look forward to seeing it. I might like to have a skim-read of it 
beofre the workshop, do forward me a link. (Though I will probably not have 
time to give you comments, sorry)

Again, thank you very much for the comments and I look forward to meeting you 
at the workshop.

Andrei Serjantov.

P.S. How's the ice looking in New Hmapshire? :-))



----- End forwarded message -----