Hidden Descriptor and DHT

[Nick Mathewson]

On Tue, May 02, 2006 at 01:15:56PM -0400, Nick Mathewson wrote:
> On Mon, May 01, 2006 at 01:30:04PM -0500, Krishna Sankar wrote:
> 
> Hi, Krishna, and thanks for your interest!  I've tried to answer your
> questions, and I've written a bit more about the security issues that
> exist, and about Tor's current scalability issues.

Oops.  Peter Palfrader just had pointed out to me that the subject
line was about hidden service descriptors, but my answer was about
router descriptors.  I'll go through and answer again.  I'm omitting
the questions where my answers are the same for both kinds of lookup.

> > 	b)	How many servers and how many entries would normally
> > 	be there ? Would help if I have some order of magnitude - back
> > 	of the envelope type calculations
> 
> It's hard to say; right now, we've got over 500 Tor servers, of which
> most could be directory caches.  We also have 5 directory authorities.
> The reason it's hard to say how many entries and servers we'd have in
> a DHT scenario is that the whole point of changing our directory
> structure would be to scale to more servers than we have now.

Still unknown; we don't track the number of hidden services we have
now, but I bet the current system would start to suffer fall over at
around 10K entries.

> > 	f)	Haven't yet focused on the security aspects, which is
> > 	my next TBD. Thoughts ?
> 
> The security implications are *critical*; you shouldn't even be
> thinking about stuff like rebalancing until you have those settled.
> It is far easier to come up with a DHT algorithm that works than a DHT
> algorithm that works in the presence of a strong attacker trying to
> break it, or to use it in order to subvert users' anonymity.

This is still right.  It's still problematic if an attacker can learn
which user wants which hidden service, or hand out different versions
of a hidden service descriptor to different users, or suppress a
hidden service.  Also, we want it to be hard to learn a list of hidden
services.


yrs,
-- 
Nick Mathewson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 654 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20060502/015813b2/attachment.pgp>