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@lists.torproject.org Sent: ‎Wednesday‎, ‎June‎ ‎3‎, ‎2015 ‎9‎:‎00‎ ‎PM To: tor-dev@lists.torproject.org

Send tor-dev mailing list submissions to tor-dev@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@lists.torproject.org

You can reach the person managing the list at tor-dev-owner@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@gmail.com To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: 9BC4820F-A4E9-4168-BFCF-0E292524B4DB@gmail.com Content-Type: text/plain; charset="us-ascii"

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512

https://trac.torproject.org/projects/tor/ticket/16276

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

Message: 3 Date: Tue, 02 Jun 2015 19:47:33 -0400 From: "l.m" ter.one.leeboi@hush.com To: tor-dev@lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: 20150602234733.2D552E04C1@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@inexplicity.de To: tor-dev@lists.torproject.org Subject: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary Message-ID: 556EE71D.5030507@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev

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

End of tor-dev Digest, Vol 53, Issue 6 **************************************