[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Directory Server Decentralization

Thus spake Raynardine (raynardine@xxxxxxxxxxx):

> On 1/30/2013 11:58 AM, unknown wrote:
> > On Tue, 29 Jan 2013 19:49:23 -0600
> > Raynardine <raynardine@xxxxxxxxxxx> wrote:
> >
> >> I just wanted to ask here in Tor-Talk where the efforts to decentralize
> >> the Tor directory servers have gone so far?
> > One of the goals of centralizing is protect Tor against attacks
> > based on the desynchronisation and dividing stats for users.
> >
> > Without unified consensus from DA available to all users synchronously,
> > an adversary can effectively divide users to small anonimity sets.
> >
> > IMHO that points to some your others proposals to.
> Then what would you do about ISPs that trivially innumerate the entire
> public relay list from a directory authority, and block every last one
> of them? What happens if a government (such as the United States)
> demands the private keys for the Directory Authorities? Would you even
> know if it has already happened years ago?

Authority key theft is a serious concern, since an adversary who is able
to maintain control of a majority of the consensus signing keys can
generate fake consensuses, possibly feeding them only to specific users
under targeted attack.

Right now, we try to mitigate this by yearly rotating each authority's
consensus signing key. Most/all authority operators keep the key that
authenticates these rotated consensus keys offline.

Longer term, I'm interested in having some form (or better: many forms)
of multipath consensus validation:

Note that it's possible for an enterprising individual to start working
on some form of #7126 without really modifying any existing tor C code.

For example, a couple python scripts and a public signed git
repository would be enough to be able to provide multipath consensus
validation using the existing consensus data today. One could even use a
Tor Controller library such as Stem, txtorcon, or pyTorCtl to provide a
client-side tool that automatically stores consensus history for later
out-of-band comparison against the public git repo, or even for live
multipath validation.

Might be a fun intro project for someone interested in getting involved
in Tor, actually, and it would potentially be a helpful validation tool
for people currently under extremely censored/filtered/targeted attack

Mike Perry

Attachment: signature.asc
Description: Digital signature

tor-talk mailing list