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@xxxxxxxxxxxxxxxxxxxx
Sent: âWednesdayâ, âJuneâ â3â, â2015 â9â:â00â âPM
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Send tor-dev mailing list submissions to
tor-dev@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxx
You can reach the person managing the list at
tor-dev-owner@xxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <9BC4820F-A4E9-4168-BFCF-0E292524B4DB@xxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Date: Tue, 02 Jun 2015 16:52:00 +0000
From: nusenu <nusenu@xxxxxxxxxxxxxxx>
>
> 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@xxxxxxxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <556E271C.20501@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=windows-1252
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
https://trac.torproject.org/projects/tor/ticket/16276
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJVbiccAAoJEFv7XvVCELh0/rUP/i7Q/cZwYaklkvHAaqmsDffK
x8J77/21/5ppN1kyPd8jI7M8ktOC+1uqhV4mlf5CyidKR+2kAhhPYjfX57xQ1sbv
OJwDq33EbQiTk/ed3DLQdQpbrt7fqaAzZi3+q2NIKMx2/GFRs6Sxnp7D9b69TEt3
WgW2sEuAuexl//HU01dKxPXp6+5EiW6UBz0eUJcTz4WUf/+CltRBg4sbBXImls3w
J5mLqMNwyrRT/StTZB5oSMHsOfxQGgGGJppT0l91onQLzpM1A38ZtgN2zs5tD6T9
OSl7hwhUJHaWR3mg9vDywXO0CQ8tTadfZLGtDU0q5H88vU00jTRW1XA7bKLxtLqY
INu9APIjnOhaatVTRGhJMMvP/Vuk6OE/L9n2FBw5FAPxmJ3Tn0+NwElamYizq7o8
AMNpWcfjHxAiH7R9PEuhwYyNktlBz3Swm4uNFvSGPaJsm99lxJLmd7ko9qrxd5Cm
WcmQvPpfXN9Ym5iTWlMpu17MLmBGb2YgshFv+fTViCY1JwaEqAlTP+5/m2XmnM2x
8CZgNHjL1C7QWffx6AQYqcoAP183ClR3MD9poan7LMYfaqxXIbLceCzMOKeu9Ptt
KPAdPAvACngB9kz43oQeJanE/nmjW90j/hr5oPezL57ayJEvpRiT+cmkkRTT2RvB
Aj2Q3IqrXhOzTJkR+N94
=pTF3
-----END PGP SIGNATURE-----
------------------------------
Message: 3
Date: Tue, 02 Jun 2015 19:47:33 -0400
From: "l.m" <ter.one.leeboi@xxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: Re: [tor-dev] onionoo: bug in family set detection?
Message-ID: <20150602234733.2D552E04C1@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxx>
To: tor-dev@xxxxxxxxxxxxxxxxxxxx
Subject: [tor-dev] Researching Tor: Quantifying anonymity against a
global passive adversary
Message-ID: <556EE71D.5030507@xxxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
------------------------------
End of tor-dev Digest, Vol 53, Issue 6
**************************************