- tor-dev - lists.torproject.org

[Onionoo] When is the system property onionoo.cron.runonce set?
by l.m 15 Jun '15

15 Jun '15

Hello, So I've been playing with Onionoo's source and I cannot find where this property is set. When the main class for the cron updater runs it checks for the property existence and returns a string "true" if not found or unset. This "true" is used to evaluate the first time update. I cannot see where the property is updated and so I get one-time updater each time. I can add the code to set the property, and all's well, but I wanted to check to make sure I'm not missing something. I cloned from the git repo. Thanks --leeroy

2 1

Sanitizing bridge descriptors containing ed25519 fields
by Karsten Loesing 13 Jun '15

13 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Forwarding from a private thread with Nick. - -------- Forwarded Message -------- Subject: Re: Whoops Date: Fri, 29 May 2015 21:20:57 +0200 From: Karsten Loesing <karsten(a)torproject.org> To: Nick Mathewson <nickm(a)torproject.org> Ugh, long mail ahead. This turns out to be more difficult than expected... On 29/05/15 19:29, Nick Mathewson wrote: > On Fri, May 29, 2015 at 11:04 AM, Karsten Loesing > <karsten(a)torproject.org> wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Sure! >> >> My main question is which of these new fields we'll have to >> sanitize in bridge descriptors. >> >> The current idea of sanitizing bridge identities is that Tonga >> would give out server descriptors if you give it a bridge >> identity. We want to avoid that, which is why we're SHA1()'ing >> fingerprints and removing cryptographic material. >> >> What about the new identity? Would we have to sanitize that in >> any way? And if so, would we want to SHA1() it, or is there a >> more ed25519y way to do this? >> >> I guess the better question might be: are there plans for Tonga >> to give out descriptors if you tell it an ed25519 identity? If >> not, do you see any potential trouble in leaving it unchanged in >> sanitized bridge descriptors? >> > > I would suggest that we sanitize all the crosscert stuff, and the > ed25519 identity, and the ed25519 signing cert. Does this need to > be done using some language I know? If so I'll be happy to hack > it up for you if you point me to the current code that does it. Thanks for the offer, really, but if I can, I'd rather want to write this code myself once I know what it's supposed to do. The reason is that setting up this code and providing you with sample data might be more effort than writing it myself. Hope that's okay, too. Only if you're curious, here's the current code that sanitizes bridge descriptors: https://gitweb.torproject.org/metrics-db.git/tree/src/org/torproject/ernie/… But feel free to ignore that code, and let's talk conceptually or by example. > (The authority might someday give out bridges based on this > information. Who knows? Not me. Better to be safe than sorry > IMO.) Okay. > To sanitize an ed25519 identity, i'd suggest SHA256. Best avoid > SHA1. Sure, that would work. By the way, here's how we're currently sanitizing bridge descriptors: https://collector.torproject.org/formats.html#bridge-descriptors Following those steps, I'd do the following things (quoting an actual bridge descriptor as input here; edit: scrubbed potentially sensitive fields, sorry for the linebreaks!): > router euler [scrubbed] 8000 0 0 identity-ed25519 -----BEGIN > ED25519 CERT----- [scrubbed] -----END ED25519 CERT----- Base64-decode that block, throw it into SHA256(), base64-encode the result, format as block. But wouldn't the result be much shorter? There's no new "fingerprint" equivalent, like "fingerprint-ed25519", is there? Whatever we do here, we should make it simple enough for bridge operators to do, too, if they want to look up their bridge in Atlas or Globe. hex-encode(SHA1(hex-decode(fingerprint))) seemed okay. We should try to find something similar for ed25519 identities. (We could also have tor log its "hashed ed25519 identity", but that only works for people looking at logs.) > platform Tor 0.2.7.1-alpha-dev on Linux protocols Link 1 2 Circuit > 1 published 2015-05-29 17:53:38 fingerprint [scrubbed] uptime 2 > bandwidth 14971520 104857600 63488 extra-info-digest [scrubbed] > [scrubbed] IIRC (and it's been a while...), I'd replace E07A... with its SHA1. So, I guess I'd replace YZpo... with its SHA256. Note that the extra-info descriptor would contain a "router-digest" line with the SHA1 of E07A... and be stored in a file using that identifier. In the distant future, we'd probably store extra-info descriptors under their SHA256. > onion-key -----BEGIN RSA PUBLIC KEY----- [scrubbed] -----END RSA > PUBLIC KEY----- signing-key -----BEGIN RSA PUBLIC KEY----- > [scrubbed] -----END RSA PUBLIC KEY----- onion-key-crosscert > -----BEGIN CROSSCERT----- [scrubbed] -----END CROSSCERT----- I'd remove the last six lines starting at "onion-key-crosscert". (The "onion-key" and "signing-key" lines/blocks would also be removed in the current code.) > ntor-onion-key-crosscert 0 -----BEGIN ED25519 CERT----- [scrubbed] > -----END ED25519 CERT----- That block would go away, too. > hidden-service-dir contact [scrubbed] ntor-onion-key [scrubbed] > reject *:* router-sig-ed25519 [scrubbed] I > guess that can go away, too. We'll probably want to put in a "router-dig-ed25519" with the SHA256 of that value. > router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END > SIGNATURE----- And here's the corresponding extra-info descriptor: > extra-info euler [scrubbed] identity-ed25519 -----BEGIN ED25519 > CERT----- [scrubbed] -----END ED25519 CERT----- Same as above, whatever that will be. > published 2015-05-29 17:53:38 write-history 2015-05-29 15:36:42 > (14400 s) 2461696,2649088,1583104,1612800,1871872,2102272 > read-history 2015-05-29 15:36:42 (14400 s) > 7444480,6047744,5960704,8019968,4823040,6364160 > dirreq-write-history 2015-05-29 13:36:18 (14400 s) > 1180672,28672,618496,28672,14336,589824 dirreq-read-history > 2015-05-29 13:36:18 (14400 s) 0,0,0,0,0,0 geoip-db-digest > 0A1F9C09E08F6F2490E8880664D4E863D1680A12 geoip6-db-digest > A6E9B5DE6F887315749B29F9C9F698215BE5240A dirreq-stats-end > 2015-05-28 19:28:08 (86400 s) dirreq-v3-ips co=8,tw=8 > dirreq-v3-reqs tw=16,co=8 dirreq-v3-resp > ok=16,not-enough-sigs=0,unavailable=0,not-found=0,not-modified=0,busy=0 > > dirreq-v3-direct-dl > complete=0,timeout=0,running=0 > dirreq-v3-tunneled-dl complete=12,timeout=0,running=0 transport > obfs3 [scrubbed]:54997 transport scramblesuit [scrubbed]:55749 > password=[scrubbed] transport fte [scrubbed]:7331 bridge-stats-end > 2015-05-28 19:28:17 (86400 s) bridge-ips co=8,tw=8 > bridge-ip-versions v4=8,v6=0 bridge-ip-transports <OR>=8,obfs3=8 > router-sig-ed25519 [scrubbed] Same > as above, whatever that will be. > router-signature -----BEGIN SIGNATURE----- [scrubbed] -----END > SIGNATURE----- So, uhm, I realize there are quite some open questions above. Hope you have some ideas, otherwise I'll think more about this tomorrow. Thanks! All the best, Karsten -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJVaMrAAAoJEJD5dJfVqbCrJC8H/j279ZhNydUoYA6aWEuZVD9P 5ERo5C+93UMhBBJLtyOmKXSBFso/wUgo1i1XwU79n6wyxxu3D8GfVnSJGhiLdEtn S6eDKkf4S/iPs+cBD8FYY/cMaj+lIehepRvzwlwV1BGSTubJXNMQTKgdh11urRTq lcxrQQNheQlQwx2ekqnTzFNDRvBVwuEGNH6GneG/0aQi4Jv4F3vkPVvOnXJz3z0u OrlhVPFp71BqkciIzv4yBEdxepXarX2zugxnLiKj0hmb6aCrM7NhjElfeoRkqeq4 ws6f997AJD6PJK97fTTTk+IaLAD6u0TtwXZv0v49On/ISSr61VU0CrJ39sCmY04= =JdbV -----END PGP SIGNATURE-----

2 7

Fwd: [PATCH]: Add Dockerfile
by Jessie Frazelle 13 Jun '15

13 Jun '15

Hi! I made a patch for running tor and/or the tor development tests in a Dockerfile. Attached is the patch and if approved you can pull from https://github.com/jfrazelle/tor.git, branch: add-dockerfile This would make running the tor test suite as easy as: docker build -t tor . docker run tor make check You can also run tor with: docker run tor Thanks! -- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu -- Jessie Frazelle 4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3 pgp.mit.edu <http://pgp.mit.edu/pks/lookup?op=get&search=0x18F3685C0022BFF3>

1 0

design for a Tor router without anonymity compromises
by coderman 12 Jun '15

12 Jun '15

a friend and i are working on a Tor router design that doesn't compromise anonymity for convenience. [0][1][2][3][4] we're soliciting feedback as part of a go / no-go decision on continuing this effort. in particular, the design is intended to meet the scrutiny of Nick M., Roger, and Mike P. as the focus on support for Tor Browser and Tor on each client indicates. --- the design and prototype code is marked "copyright Tor Project Inc. by assignment", which means that we're using a notary public to formally assign copyright ownership to the corporate entity "Tor Project, Inc.". your comments will be taken into consideration, however, please defer patches / code contributions under other owners (you) until assignment complete. --- last but not least, we're trying to eat our own dog food. all of our planning, development, and operations use hidden services, called Onion services in the document, and this bootstrap is more difficult than expected. [5] please provide feedback in reply on this thread or to me directly.[6] assuming the project continues, we will have Onion services to support collaborative development up soon. best regards, and my thanks in advance for your scrutiny! 0. "Tor Enforcing Privacy Router" http://serqet345qt265xp.onion/ 1. "Op-ed: Why the entire premise of Tor-enabled routers is ridiculous" http://arstechnica.com/security/2015/04/18/op-ed-why-the-entire-premise-of-… 2. "[tor-relays] Anonbox Project - Mike Perry" https://lists.torproject.org/pipermail/tor-relays/2014-October/005541.html 3. "[tor-relays] Anonbox Project - Roger Dingledine" https://lists.torproject.org/pipermail/tor-relays/2014-October/005544.html 4. "[tor-talk] Cloak Tor Router (thread)" https://lists.torproject.org/pipermail/tor-talk/2014-November/035436.html 5. "Onion services" came in behind "Tor sites" because sites felt too web browser focused. we're trying to avoid the legacy "hidden services" nomenclature. 6. i have a long history of extreme dislike for encrypted email, key servers, web of trust, and other moral hazards. however, if you encrypt to my key you can send private mail, if desired. note that some encrypted email clients will fail insecure if the intended recipient doesn't match a keyring identifier! https://peertech.org/keys/0x65A847E7C2B9380C-pub.txt

5 11

[Onionoo] Resource requirements for serving static data
by l.m 11 Jun '15

11 Jun '15

Hello, When I check the running Onionoo server at onionoo.torproject.org I see it is using Apache. In the installation documentation running the web service starts the embedded Jetty. The first question I have is: which is responsible for the static components of the official Onionoo server? Does the running Apache serve (or cache) the static data or just forward to the embedded Jetty. Thanks --leeroy

2 1

Re: [tor-dev] Adding a NotDir router status flag
by teor 09 Jun '15

09 Jun '15

> Date: Fri, 29 May 2015 14:24:33 +0300 > From: s7r <s7r(a)sky-ip.org> > > Signed PGP part > Hi Matt, > > Nice to hear there's ongoing work for this proposal. > > I also see the NotDir flag as useful for migration, because for quite > some time after prop 237 is implemented we will still have relays in > the consensus which will have DirPort open (separate from ORPort). A > client needs to know to make directory requests on DirPort for the > relays with V2Dir flag, and know to make directory requests on ORPort > for the relays which only have ORPort open and NotDir flag. > > > After (hopefully) medium time we can drop the V2Dir flag (we are way > passed from V2 directory anyway) and after longer time we can also > drop NotDir. I guess this depends if directory requests on ORPort will > be only implemented in new Tor releases or also backport? It's unlikely we'd backport a feature of this magnitude - we already ran into issues (mainly with hidden services) when the authorities assumed that relays with only an ORPort would answer directory requests, but the relays weren't actually doing so. > I guess we > can say it's safe to drop both flags when over 95% of the relays > respond to directory requests on ORPort. We will just need Valid flag > to make sure we can separate the relays which try to poison directory > data. When relays have AccountingMax set, they disable their DirPort to maximise the bandwidth used for relaying Tor cells. This implies that they should also ask for the NotDir flag, and refuse to respond to directory requests on both the DirPort and ORPort. (We don't want relays that are already bandwidth-constrained receiving directory requests that we know they'll refuse - this is a waste of their bandwidth.) Does this need to be part of prop 237? Since the NotDir flag is still useful in with AccountingMax, we should reconsider the plan to drop NotDir in a few releases' time. 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

2 1

Paper on domain fronting (meek)
by David Fifield 09 Jun '15

09 Jun '15

I and my colleagues at Berkeley, Lantern, and Psiphon wrote a paper on domain fronting, the censorship circumvention technology that underlies the meek pluggable transport among other systems. It's going to appear at the PET Symposium on June 30, 2015. If you've been following along, you know most of the story for Tor, but the paper also includes the story of deployment on Lantern and Psiphon. I'm trying an experiment. Normally this kind of paper is published as a PDF. I find it annoying to read PDF papers on the web, where you have to scroll to the end to find URLs for references (if you're lucky). So I made an HTML version of what's going to get published in the proceedings. https://www.bamsoftware.com/papers/fronting/ I have to admit, though, that PDF is nice for printing out and reading offline, so here is the PDF version: https://www.bamsoftware.com/papers/fronting.pdf

1 0

additional triggers for DocTor?
by nusenu 05 Jun '15

05 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Damian, does DocTor's design allow for triggers that alert if a certain amount of relays signed up within one day or within a week (instead of within one hour)? Another trigger could be the last_restarted timestamp. If that makes sense I would file feature requests on trac and provide some possible thresholds. Example of an event that would trigger then (2015-04-01): https://lists.torproject.org/pipermail/tor-talk/2015-April/037384.html -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJVcdCSAAoJEFv7XvVCELh0l5IP/R0NeXImuchqastZcg4T4PK7 Qy5VmFrWBdG9AOnypxIMgzVF5/M+hKjRgbbAp9/VrRXqpbFCgnChnQvqyJcW1nB0 AYGfqEUfavTBthbtTfq6g43BLBZke0olBMVFlKHaAYTidXMabrY0OlZ3QjdHt1Sx DovQ/zGVX263VR1YZimXom1xokCDm7J51vPURjx9BLrBQ2zdEGvOWWwdT+w1CiaK iH4I0AGUPZfLxxLU7rCorFAIV2AyKTT97EN9lQlD3TtPmoDiZdhPthR2MRKVruEP 3Kt76VDMRPro6oKo2d3sk5UFuyh0Hg+yqJhTJhjdZ0w/ZQtbIjlkHbnfSqgthEPL fi2XKQrX1BSfbQpsig70FRFHgKEQVzplXLlca9o1sn52GrwdY8fzNLc0p8xZiFSc xoognuyER4IgLP10c2QsYSoCx50yfpYOxDZIEFVIelDDKGIqVQzR/rGRwBfXBcn/ 598SPhka+h0BK/NudG/k5qRlsdWpQdygeAfDBUUO6AxHaIH2P96Pe1CfxNkoMGX4 TWZ2+pTXye6wdiFhdhDYGPuCtmOgI5GQ5alHEvsk3s7/n0YitRRNHNiNe3SGw7UN hX6HQuWmxD5J/D1fcj5gC/gJZxkeluTRO6iOP1AoNAqP9XGgQeT7uwhL+FzT65V5 GlMIH20AeBn2FWIesaxf =Ia4Q -----END PGP SIGNATURE-----

2 1

Re: [tor-dev] onionoo: bug in family set detection?
by saitosean＠ymail.com 05 Jun '15

05 Jun '15

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(a)lists.torproject.org Sent: ‎Wednesday‎, ‎June‎ ‎3‎, ‎2015 ‎9‎:‎00‎ ‎PM To: tor-dev(a)lists.torproject.org Send tor-dev mailing list submissions to tor-dev(a)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(a)lists.torproject.org You can reach the person managing the list at tor-dev-owner(a)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(a)gmail.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <9BC4820F-A4E9-4168-BFCF-0E292524B4DB(a)gmail.com> Content-Type: text/plain; charset="us-ascii" Date: Tue, 02 Jun 2015 16:52:00 +0000 From: nusenu <nusenu(a)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…> ------------------------------ Message: 2 Date: Tue, 02 Jun 2015 21:58:52 +0000 From: nusenu <nusenu(a)openmailbox.org> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <556E271C.20501(a)openmailbox.org> 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(a)hush.com> To: tor-dev(a)lists.torproject.org Subject: Re: [tor-dev] onionoo: bug in family set detection? Message-ID: <20150602234733.2D552E04C1(a)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…> ------------------------------ Message: 4 Date: Wed, 03 Jun 2015 13:38:05 +0200 From: Florian R?chel <florian.ruechel.tor(a)inexplicity.de> To: tor-dev(a)lists.torproject.org Subject: [tor-dev] Researching Tor: Quantifying anonymity against a global passive adversary Message-ID: <556EE71D.5030507(a)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(a)lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev ------------------------------ End of tor-dev Digest, Vol 53, Issue 6 **************************************

2 1

1st status report for OnioNS
by OnioNS Dev 04 Jun '15

04 Jun '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 For this first status update on my SoP project (the Onion Name System), I'd like to give a quick run-down of where the project currently is. I would consider OnioNS ahead of schedule as I made significant progress on it for the paper before the SoP program officially began. The following features are in place: *Client-side:* * A reliable Stem script that intercepts a .tor domain and sends it to the OnioNS client. It sets Tor to leave streams unattached, then auto-attaches non .tor streams, and rewrites .tor to .onion before attaching. Thank you arma! * Reliable IPC communication over a localhost TCP socket between the Stem script and the OnioNS client. The IPC syntax is simple enough to support telnet or other tools. * Ability to specify the IP of a name server (essentially a Mirror, but the name server isn't mirroring anything since the Synchronization protocol isn't there yet). * JSON communication over a Tor circuit (SOCKS username "OnioNS") to a name server. * The ability to verify the signature and proof-of-work of a Record. *HS-side:* * The capability to create and validate (through scrypt proof-of-work) a Record. * Prompts to allow a user to specify the domain name and subdomain-destinations that they want for their hidden service. * The printout in JSON of a Record, which one can copy and send over email or IRC until I get the upload protocols in place. *Server-side:* * JSON communication to make life easy. * TCP server for receiving a .tor domain and returning a Record. * Support for multiple Records. * The ability to accept and cache a new Record. * Construction of a Merkle tree and RSA-signing of the root. * Ability to find a Record in the Merkle tree, or to find a subtree that proves a domain's non-existence. *General:* * A hidden service for this project. * Reliance on Botan rather than OpenSSL. The difference is night and day. Thank you Yawning! * A Record for example.tor and several others for testing and illustrative purposes. * Clean and organized code. The style is similar to Chromium with the exception that I put three spaces between each method. I enforce the style with clang-format. * A basic but functional manpage. * Support for Clang and GCC, with Clang being the preferred compiler for development and GCC is used when packaging. * Packaging into a PPA on Launchpad for Ubuntu 14.04 and beyond, so "tor-onions" can be installed and updated through apt-get. I also support Debian 8+ but do not currently package for it. * Packaging for x86, amd64, and armhf, so I'm supporting Pis/BBB/Odroid as well. * Many labeled tickets on Github to improve workflow. * Signed git tagging. As you can imagine, this constitutes the bulk of the essential functionality. The remainder is primarily networking and server-side protocols, such as the Quorum, the Synchronization and Broadcast (upload) protocols, various algorithms, and so on. Those are next. I'm temporarily in a remote location and the Internet here is slow and quite spotty, so the project's hidden service is down and I haven't tested the latest commits over the network. However, once I have the Internet figured out I'll post a prototype here that everyone can test if they like. It's a centralized DNS at the moment, so spreading it out is next on the list. - - Jesse V. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJVcJMiAAoJEK2XNk/CC+yAPAAH/3uFvSXRwpq8QfE7o///Cc5a 5w3NwTP06pp1+AQ8RNUhmt17z3eHYOJJpP6zP4uwEzwAnNbUAs/8GiGdDOUj5Se3 kCUPh8/0s+yHWb02ctVhOYE32CouUVQHnswtuDRjz9KPO9Z3yG2d16TUINOurfKf tigUlgrRaW5pOIm0CQ2z4epi7FFKwdPjdTpsdbZURZTwybCiS4vgfN08iaIRZ/3M 9tz1tfQZH303yTQwubdYf9l99XJlxBtFBFjJlJzCze7iOEVD+j0fHRKk6OM/wouD kjKrarEQQACQhUzNssAr2/Yv/odYvshJYSLe/7/eoGH7zkKof0rbcBQPyLUpZoU= =B+Hz -----END PGP SIGNATURE-----

1 0