[tor-dev] onionoo: bug in family set detection?

Fri Jun 5 15:06:22 UTC 2015

I ran some tests to investigate said onionoo bug.

My test case is simply as follows:

Get the set of all running relays from onionoo (ignore non-running relays for the sake of convenience)
For each relay (relay A) in the set, and for each relay (relay B) in relay A’s family, check to see whether relay A is included in relay B’s family. If not, there is no bidirectionality.

The results (Number of running relays = 6774):

Number of bidirectional pairs: 5911

Number of non-bidirectional pairs: 532

Number of pairs where either relay has not family list at all: 49

Sean

From: tor-dev-request at lists.torproject.org
Sent: ‎Wednesday‎, ‎June‎ ‎3‎, ‎2015 ‎9‎:‎00‎ ‎PM
To: tor-dev at lists.torproject.org

Send tor-dev mailing list submissions to
 tor-dev at lists.torproject.org

To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
or, via email, send a message with subject or body 'help' to
 tor-dev-request at lists.torproject.org

You can reach the person managing the list at
 tor-dev-owner at lists.torproject.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of tor-dev digest..."

Today's Topics:

   1. Re: onionoo: bug in family set detection? (teor)
   2. Re: onionoo: bug in family set detection? (nusenu)
   3. Re: onionoo: bug in family set detection? (l.m)
   4. Researching Tor: Quantifying anonymity against a global
      passive adversary (Florian R?chel)

----------------------------------------------------------------------

Message: 1
Date: Wed, 3 Jun 2015 07:11:48 +1000
From: teor <teor2345 at gmail.com>
To: tor-dev at lists.torproject.org
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <9BC4820F-A4E9-4168-BFCF-0E292524B4DB at gmail.com>
Content-Type: text/plain; charset="us-ascii"

Date: Tue, 02 Jun 2015 16:52:00 +0000
From: nusenu <nusenu at openmailbox.org>
> 
> teor:
> > MyFamily requires bidirectional declarations to be effective.
> 
> I'm aware of that fact ;)
> 
> > In this case: OnionOO appears to correctly implement the
> > bidirectional MyFamily logic
> 
> Apparently it doesn't.
> 
> Since onionoo says there is a bidirectional "connection" (family) between
> 5510FC1736B16D46D3F2DDA5011995C478D42594 =>
> 0C77421C890D16B6D201283A2244F43DF5BC89DD
> 
> but there is none.. (as explained in my last email)
> 
> Compass does *not* say that there is a bidirectional connection
> between those relays..  onionoo says there is one even though I can't
> see it, do you see it?

I'm sorry, I must have got the onionoo and Compass results mixed up somehow.

In Compass, I see that:
5510FC1736B16D46D3F2DDA5011995C478D42594 has no family.

In Globe/Atlas (based on onionoo), I see that:
5510FC1736B16D46D3F2DDA5011995C478D42594 has a very large family.

So my criticism of Compass actually applies to onionoo.

teor

teor2345 at gmail dot com
pgp 0xABFED1AC
https://gist.github.com/teor2345/d033b8ce0a99adbc89c5

teor at blah dot im
OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150603/c42651ce/attachment-0001.sig>

------------------------------

Message: 2
Date: Tue, 02 Jun 2015 21:58:52 +0000
From: nusenu <nusenu at openmailbox.org>
To: tor-dev at lists.torproject.org
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <556E271C.20501 at openmailbox.org>
Content-Type: text/plain; charset=windows-1252

Message: 3
Date: Tue, 02 Jun 2015 19:47:33 -0400
From: "l.m" <ter.one.leeboi at hush.com>
To: tor-dev at lists.torproject.org
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <20150602234733.2D552E04C1 at smtp.hushmail.com>
Content-Type: text/plain; charset="utf-8"

Hello,

DirAuth's can cache multiple versions of the descriptor  and serve
what appears to be the newest in a given consensus interval.  This
coupled with routers publishing descriptors at least every 18  hours,
but potentially sooner. What you describe doesn't appear to  be a bug
in Onionoo because a consensus exists for which the family is 
declared as you describe in the last known good descriptor.

At the moment you describe Atlas doesn't show:

[1] last published 2015-06-02 17:44:27 (and [2] may still have entered
hibernate)
[2] last published 2015-06-02 09:40:45 (and [1] may not be running, or
have a last known good descriptor at DirAuths)

This doesn't take into account the possibility  of a router
hibernating (info not always available) at times between  consensus
taken or valid. A router can be running but unavailable due to 
accounting. This looks like a result of cached descriptors or router 
accounting. The data provided to Onionoo from metrics-lib appears 
accurate as far as network status. At least that's how it looks from a
preliminary glance at the data and spec--although please do your own
verification.

--leeroy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150602/35e00c6f/attachment-0001.html>

------------------------------

Message: 4
Date: Wed, 03 Jun 2015 13:38:05 +0200
From: Florian R?chel  <florian.ruechel.tor at inexplicity.de>
To: tor-dev at lists.torproject.org
Subject: [tor-dev] Researching Tor: Quantifying anonymity against a
 global passive adversary
Message-ID: <556EE71D.5030507 at inexplicity.de>
Content-Type: text/plain; charset=utf-8

Hi there,

I am currently writing my Master's thesis about Mix networks & Tor (was
on list previously). I am currently at a point, where I'd like to
practially quantify anonymity. That is, given a pcap, I want to anaylze
how successful an adversary can determine whether a specific client
talked to a specific service. Since I run all of this in a simulation
(using Shadow), I have access to ground truth and can determine the
traffic, network size, etc. arbitrarily.

The idea behind all of this is to integrate a Mix relay on each Tor node
and to watch how the adversarys success behaves. However, I have a hard
time finding material on such attacks, i.e. papers that closely examine
this scenario (and perhaps have conducted some simulation and/or
measurements themselves, beyond simple theory). The thing is that this
is only part of the research and I'd really prefer if I could build this
upon work of others instead of starting from scratch.

Do any of you know of such papers or corresponding research?

Regards,
Florian

------------------------------

Subject: Digest Footer

_______________________________________________
tor-dev mailing list
tor-dev at lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

------------------------------

End of tor-dev Digest, Vol 53, Issue 6
**************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150605/2dbf5e2c/attachment.html>