FEATURE IDEA: Hidden Directory Authorities
arma at mit.edu
Wed Nov 28 03:25:44 UTC 2007
On Mon, Nov 19, 2007 at 12:29:53AM -0800, Kyle Williams wrote:
> I know that Tor has the PrivateDir option, which uses an Onion Router
> to make the request to the DA to retrieve updated cached-* documents.
> However, this option will not
> function without a pre-cached copy of the cached-routers documents
> because it wouldn't know of an Onion Routers to tunnel the request
> Basically you need a pre-cached copy of cached-routers for PrivateDir
> to work, right?
> (Please correct me if I am wrong here.)
Actually, the config option is called __AllDirActionsPrivate. The "__"
at the front means that it's a config option that's meant to be settable
by the Tor controller -- it assumes the controller is using an alternate
mechanism for bootstrapping. It also means that when the controller
issues a 'saveconf' command, that config option doesn't get saved.
> So the questions that entered my mind were:
> * Could Directory Authorities use an .onion address instead of an IP
> address if a pre-cached copy of cached-routers was distributed with
> the initial download of Tor?
Yes, in theory this would work.
> * Would this make the Directory Authorities more resistant to digital
> & physical attack?
Yes, against a weak attacker. Against a stronger attacker, my impression
is that hidden services are less secure than normal Tor circuits. This is
because the hidden service stays in one place and makes an ever-growing
pile of hints for the attacker. Entry guards help but don't totally
resolve the issue. But as usual, more research remains. :)
> * Are "guard" nodes the same as "valet" nodes?
> The wording of "guard" nodes  sounds very similar to the concept of
> "valet" nodes , but I'm not quite sure if these are the same. Are
>  Making Anonymous Communications
> ( http://www.onion-router.net/Publications/Briefing-2004.pdf )
>  Locating Hidden Servers
> ( http://www.onion-router.net/Publications/locating-hidden-servers.pdf )
No, they're different. Btw, for your , you should actually be
looking at http://freehaven.net/anonbib/#valet:pet2006
> Since the DAs would be the most logical place for an attacker to DoS
> or attack, I was thinking that it would make sense if the DAs couldn't
> be found physically or by IP.
> To start a network, I was think of using 3 DAs with 8 nodes. The
> nodes would act as rendezvous points, introduction points, valet/guard
> points, entry, middle, and exit nodes.
> If the DAs .onion information and 8 startup nodes information was
> pre-cached when Tor is download, would that be enough to keep the DA's
You would effectively still be limited by the robustness of those
8 nodes. If you're fine with that, why not make all 8 of them into
> Now the big question. What type of attacks would this be prone to?
> After reading , it became clear that someone could attack
> Introduction Points to reveal the true location of the hidden service.
> But the 'valet' (or 'guard'?) node design model would significantly
> help reduce the probability of this attack being successful.
Last I checked, the valet design needed more thinking before I was
convinced it would work well in practice. For one, somebody needs to
take it from the 'research paper' phase to the 'spec proposal' phase.
> So, if
> the DA's are acting as a hidden service, in theory, Introduction and
> Valet Points wouldn't be able to distinguish regular hidden services
> from the DA's hidden service.
> I know that by hiding the DA's, every downloaded package of Tor would
> have to contain an up-to-date copy of the cached-routers. Could a
> "cached-onions" file be introduced into the design to make it clear
> which are Onion Routers and which are Hidden Services?
I don't follow.
Also, note that not all "main" directory authorities need to be hidden
service directory authorities, and vice versa.
Hope that helps,
More information about the tor-dev