[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[freehaven-dev] (FWD) Re: Anonymizing system for IPTPS
[Forwarded, because Andrei is not subscribed to the freehaven-dev list.]
----- Forwarded message from email@example.com -----
From: Andrei Serjantov <Andrei.Serjantov@cl.cam.ac.uk>
To: Michael J Freedman <mfreed@MIT.EDU>
Cc: Andrei.Serjantov@cl.cam.ac.uk, firstname.lastname@example.org
Subject: Re: Anonymizing system for IPTPS
Date: Tue, 19 Feb 2002 14:24:38 +0000
> I recently read your paper "Anonymizing Censorship Resistant Systems"
> for the upcoming peer-to-peer workshop at MIT. It makes several
> interesting points. I had some questions and thought I'd offer some
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
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
> 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.
P.S. How's the ice looking in New Hmapshire? :-))
----- End forwarded message -----