<html><head><style data-externalstyle="true"><!--
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst, p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle, p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast {
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
line-height:115%;
}
--></style></head><body><div data-externalstyle="false" dir="ltr" style="font-family:Calibri,'Segoe UI',Meiryo,'Microsoft YaHei UI','Microsoft JhengHei UI','Malgun Gothic','Khmer UI','Nirmala UI',Tunga,'Lao UI',Ebrima,sans-serif;font-size:12pt;"><div>I ran some tests to investigate said onionoo bug.</div><div>My test case is simply as follows:</div><div> </div><ol style="padding-top: 0px; padding-bottom: 0px; margin-top: 0px; margin-bottom: 0px; list-style-type: decimal;"><li>Get the set of all running relays from onionoo (ignore non-running relays for the sake of convenience)</li><li>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.</li></ol><div> </div><div>The results (Number of running relays = 6774):</div><div> </div><div>Number of bidirectional pairs: 5911</div><div>Number of non-bidirectional pairs: 532</div><div>Number of pairs where either relay has not family list at all: 49</div><div> </div><div data-signatureblock="true">Sean</div><div data-signatureblock="true"> </div><div style="padding-top: 5px; border-top-color: rgb(229, 229, 229); border-top-width: 1px; border-top-style: solid;"><div><font face="Calibri, 'Segoe UI', Meiryo, 'Microsoft YaHei UI', 'Microsoft JhengHei UI', 'Malgun Gothic', 'Khmer UI', 'Nirmala UI', Tunga, 'Lao UI', Ebrima, sans-serif" style='line-height: 15pt; letter-spacing: 0.02em; font-family: Calibri, "Segoe UI", Meiryo, "Microsoft YaHei UI", "Microsoft JhengHei UI", "Malgun Gothic", "Khmer UI", "Nirmala UI", Tunga, "Lao UI", Ebrima, sans-serif; font-size: 11pt;'><b>From:</b> tor-dev-request@lists.torproject.org<br><b>Sent:</b> Wednesday, June 3, 2015 9:00 PM<br><b>To:</b> tor-dev@lists.torproject.org</font></div></div><div> </div>Send tor-dev mailing list submissions to<br> tor-dev@lists.torproject.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev<br>or, via email, send a message with subject or body 'help' to<br> tor-dev-request@lists.torproject.org<br><br>You can reach the person managing the list at<br> tor-dev-owner@lists.torproject.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of tor-dev digest..."<br><br><br>Today's Topics:<br><br> 1. Re: onionoo: bug in family set detection? (teor)<br> 2. Re: onionoo: bug in family set detection? (nusenu)<br> 3. Re: onionoo: bug in family set detection? (l.m)<br> 4. Researching Tor: Quantifying anonymity against a global<br> passive adversary (Florian R?chel)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 3 Jun 2015 07:11:48 +1000<br>From: teor <teor2345@gmail.com><br>To: tor-dev@lists.torproject.org<br>Subject: Re: [tor-dev] onionoo: bug in family set detection?<br>Message-ID: <9BC4820F-A4E9-4168-BFCF-0E292524B4DB@gmail.com><br>Content-Type: text/plain; charset="us-ascii"<br><br>Date: Tue, 02 Jun 2015 16:52:00 +0000<br>From: nusenu <nusenu@openmailbox.org><br>> <br>> teor:<br>> > MyFamily requires bidirectional declarations to be effective.<br>> <br>> I'm aware of that fact ;)<br>> <br>> > In this case: OnionOO appears to correctly implement the<br>> > bidirectional MyFamily logic<br>> <br>> Apparently it doesn't.<br>> <br>> Since onionoo says there is a bidirectional "connection" (family) between<br>> 5510FC1736B16D46D3F2DDA5011995C478D42594 =><br>> 0C77421C890D16B6D201283A2244F43DF5BC89DD<br>> <br>> but there is none.. (as explained in my last email)<br>> <br>> Compass does *not* say that there is a bidirectional connection<br>> between those relays.. onionoo says there is one even though I can't<br>> see it, do you see it?<br><br>I'm sorry, I must have got the onionoo and Compass results mixed up somehow.<br><br>In Compass, I see that:<br>5510FC1736B16D46D3F2DDA5011995C478D42594 has no family.<br><br>In Globe/Atlas (based on onionoo), I see that:<br>5510FC1736B16D46D3F2DDA5011995C478D42594 has a very large family.<br><br>So my criticism of Compass actually applies to onionoo.<br><br>teor<br><br>teor2345 at gmail dot com<br>pgp 0xABFED1AC<br>https://gist.github.com/teor2345/d033b8ce0a99adbc89c5<br><br>teor at blah dot im<br>OTR D5BE4EC2 255D7585 F3874930 DB130265 7C9EBBC7<br><br>-------------- next part --------------<br>A non-text attachment was scrubbed...<br>Name: signature.asc<br>Type: application/pgp-signature<br>Size: 832 bytes<br>Desc: Message signed with OpenPGP using GPGMail<br>URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150603/c42651ce/attachment-0001.sig><br><br>------------------------------<br><br>Message: 2<br>Date: Tue, 02 Jun 2015 21:58:52 +0000<br>From: nusenu <nusenu@openmailbox.org><br>To: tor-dev@lists.torproject.org<br>Subject: Re: [tor-dev] onionoo: bug in family set detection?<br>Message-ID: <556E271C.20501@openmailbox.org><br>Content-Type: text/plain; charset=windows-1252<br><br>-----BEGIN PGP SIGNED MESSAGE-----<br>Hash: SHA512<br><br>https://trac.torproject.org/projects/tor/ticket/16276<br>-----BEGIN PGP SIGNATURE-----<br><br>iQIcBAEBCgAGBQJVbiccAAoJEFv7XvVCELh0/rUP/i7Q/cZwYaklkvHAaqmsDffK<br>x8J77/21/5ppN1kyPd8jI7M8ktOC+1uqhV4mlf5CyidKR+2kAhhPYjfX57xQ1sbv<br>OJwDq33EbQiTk/ed3DLQdQpbrt7fqaAzZi3+q2NIKMx2/GFRs6Sxnp7D9b69TEt3<br>WgW2sEuAuexl//HU01dKxPXp6+5EiW6UBz0eUJcTz4WUf/+CltRBg4sbBXImls3w<br>J5mLqMNwyrRT/StTZB5oSMHsOfxQGgGGJppT0l91onQLzpM1A38ZtgN2zs5tD6T9<br>OSl7hwhUJHaWR3mg9vDywXO0CQ8tTadfZLGtDU0q5H88vU00jTRW1XA7bKLxtLqY<br>INu9APIjnOhaatVTRGhJMMvP/Vuk6OE/L9n2FBw5FAPxmJ3Tn0+NwElamYizq7o8<br>AMNpWcfjHxAiH7R9PEuhwYyNktlBz3Swm4uNFvSGPaJsm99lxJLmd7ko9qrxd5Cm<br>WcmQvPpfXN9Ym5iTWlMpu17MLmBGb2YgshFv+fTViCY1JwaEqAlTP+5/m2XmnM2x<br>8CZgNHjL1C7QWffx6AQYqcoAP183ClR3MD9poan7LMYfaqxXIbLceCzMOKeu9Ptt<br>KPAdPAvACngB9kz43oQeJanE/nmjW90j/hr5oPezL57ayJEvpRiT+cmkkRTT2RvB<br>Aj2Q3IqrXhOzTJkR+N94<br>=pTF3<br>-----END PGP SIGNATURE-----<br><br><br>------------------------------<br><br>Message: 3<br>Date: Tue, 02 Jun 2015 19:47:33 -0400<br>From: "l.m" <ter.one.leeboi@hush.com><br>To: tor-dev@lists.torproject.org<br>Subject: Re: [tor-dev] onionoo: bug in family set detection?<br>Message-ID: <20150602234733.2D552E04C1@smtp.hushmail.com><br>Content-Type: text/plain; charset="utf-8"<br><br>Hello,<br><br>DirAuth's can cache multiple versions of the descriptor and serve<br>what appears to be the newest in a given consensus interval. This<br>coupled with routers publishing descriptors at least every 18 hours,<br>but potentially sooner. What you describe doesn't appear to be a bug<br>in Onionoo because a consensus exists for which the family is <br>declared as you describe in the last known good descriptor.<br><br>At the moment you describe Atlas doesn't show:<br><br>[1] last published 2015-06-02 17:44:27 (and [2] may still have entered<br>hibernate)<br>[2] last published 2015-06-02 09:40:45 (and [1] may not be running, or<br>have a last known good descriptor at DirAuths)<br><br>This doesn't take into account the possibility of a router<br>hibernating (info not always available) at times between consensus<br>taken or valid. A router can be running but unavailable due to <br>accounting. This looks like a result of cached descriptors or router <br>accounting. The data provided to Onionoo from metrics-lib appears <br>accurate as far as network status. At least that's how it looks from a<br>preliminary glance at the data and spec--although please do your own<br>verification.<br><br>--leeroy<br><br>-------------- next part --------------<br>An HTML attachment was scrubbed...<br>URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20150602/35e00c6f/attachment-0001.html><br><br>------------------------------<br><br>Message: 4<br>Date: Wed, 03 Jun 2015 13:38:05 +0200<br>From: Florian R?chel <florian.ruechel.tor@inexplicity.de><br>To: tor-dev@lists.torproject.org<br>Subject: [tor-dev] Researching Tor: Quantifying anonymity against a<br> global passive adversary<br>Message-ID: <556EE71D.5030507@inexplicity.de><br>Content-Type: text/plain; charset=utf-8<br><br>Hi there,<br><br>I am currently writing my Master's thesis about Mix networks & Tor (was<br>on list previously). I am currently at a point, where I'd like to<br>practially quantify anonymity. That is, given a pcap, I want to anaylze<br>how successful an adversary can determine whether a specific client<br>talked to a specific service. Since I run all of this in a simulation<br>(using Shadow), I have access to ground truth and can determine the<br>traffic, network size, etc. arbitrarily.<br><br>The idea behind all of this is to integrate a Mix relay on each Tor node<br>and to watch how the adversarys success behaves. However, I have a hard<br>time finding material on such attacks, i.e. papers that closely examine<br>this scenario (and perhaps have conducted some simulation and/or<br>measurements themselves, beyond simple theory). The thing is that this<br>is only part of the research and I'd really prefer if I could build this<br>upon work of others instead of starting from scratch.<br><br>Do any of you know of such papers or corresponding research?<br><br>Regards,<br>Florian<br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>tor-dev mailing list<br>tor-dev@lists.torproject.org<br>https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev<br><br><br>------------------------------<br><br>End of tor-dev Digest, Vol 53, Issue 6<br>**************************************<br></div></body></html>