[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-talk] Data storage in cached-descriptors
On Wed, May 30, 2012 at 2:38 AM, Fabio Pietrosanti (naif)
> Hi all,
> i've been thinking some days ago that the Tor infrastructure maybe a
> very valuable infrastructure also for other software that would like to
> stay distributed without a "central directory".
Basically, there are some open unsolved questions on how to do it
securely and efficiently. It'd be cool to solve them -- and it looks
like the research community could be making progress -- but I don't
think I'd want to consider it solved yet.
There's some research on this. Here are a few papers to start with,
but anybody who's serious about this should chase through their
references, and then read other works by the same authors and by
authors of related systems and attacks.
I think the Salsa paper was particularly well written, and explains a
lot of the design decisions you need to make in a p2p anonymity
There _are_ published attacks against the system, though. You might
want to stop here and see whether you can think of them before you go
Then I'd read:
It's a paper that describes attacks against a couple of other
previously existing distributed directory designs. Its "related work"
section references some more p2p anonymity network designs, and the
known attacks against them.
The approach of
provides an alternate approach for the scalability issue, but leaves
the centralized trust issue alone.
> In order to do so, a server-software for a distributed network, may also
> run a Tor Relay and write it's meta-data to cached-descriptors, de-facto
> relying on Tor's Directory Authority infrastructure.
> The question is:
> - How much "custom data" a Tor Relay can write in cached-descriptors, by
> running a Tor Relay?
> In particular i noticed the following entries as valuable to store
> custom-data without breaking other Tor relay functionalities:
> - router
> - contact
Sure, but why would you ever do that? dir-spec.txt explicitly
requires everything that handles router descriptors to allow
unrecognized fields and pass them unchanged.
tor-talk mailing list