tor-dev August 2013

tor-dev@lists.torproject.org

39 participants
42 discussions

Trac Ticket 1922
by Bao Nguyen 28 Aug '13

28 Aug '13

Providing a fix for #1922, I urge whoever has the authority to decide what folder tor is to parse. I saw /etc/torrc.d/ and /etc/tor.d/ or any others. I am going to make a patch. So which one is it?

1 0

HSDir hash ring modification
by Kang 28 Aug '13

28 Aug '13

Hello. I was reading about hidden services and a thought occurred to me regarding the hash ring used in choosing and determining the HSDirs for a hidden service. As far as I can tell the hash ring is more or less static since a relay's position is determined by their identity key, which doesn't change. I'm also under the impression that the hash ring is only used for calculation of HSDirs of hidden services. I don't have a particular method in mind, but it seems to me that you could use the "time-period" value that is used in calculation of the service's descriptor-id to shuffle the ring. This would cause the ring to be different for each hidden service, and also make its order change periodically. I imagine in particular it would make onion address enumeration attacks more difficult, since an attacker wouldn't just be able to "cast a net" over the ring for all services. Can anybody see any problems or false assumptions with this? Thanks

2 3

Trac Ticket 8291
by Bao Nguyen 27 Aug '13

27 Aug '13

Hi, I am one of the volunteer from Whonix project, a third party application. We want to use tor and modify it to parse the folder /etc/tor.d/ for configuration files. Please take a look at https://trac.torproject.org/projects/tor/ticket/8291 What is the process to get it approved and check in the file. I have modified the file src/or/config.c Who should I talk to? Thanks

3 4

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 26 Aug '13

26 Aug '13

Hello tor-dev, Apologies for submitting the report later than planned, but I was on holiday towards the end of last week. I am currently waiting for a code review for the stage 2 of the seccomp filter, which will very likely include a relatively long list of change requests. As a reminder, at the moment there should be one filter which does both syscall and parameter filtering. As a brief update the following changes were made for the past 2 weeks: - various syscall filter changes for linux 32/64 bit - dealt with issues related to the open syscall, due to the fact that we use path filtering and external dependencies happen to use 'open' with strings unprotected by the filter (libevent, getaddrinfo, openssl) - received feedback and added socket filters, which support parameter filtering only for 64 bits, since on 32 they get multiplexed on one syscall (socketcall) - waiting for review on [1] in public branch [2] For stage 3, further privileges will be dropped for different sections of code (eg. the worker threads), and the project will support multiple filters. More details may be found here [1]. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9249 [2] https://github.com/cristiantoader/tor -gsoc-capabilities/tree/gsoc-cap-stage2

1 0

Status report - Stream-RTT
by ra 26 Aug '13

26 Aug '13

Hello! Here goes my fourth status report on reducing the RTT of Tor circuits: I continued to evaluate lots of RTT-data of Tor circuits and drew some conclusions from that: *) The RTT measurements of circuits are subject to multiple influences and hence very diverse. *) There is no single distribution that fits them for all circuits. I am currently in the process of doing a demonstration of the improvement the active RTT probing yields. I delayed this report to provide some actual results but the demo is still half-baked.. Best, Robert

1 0

[GSOC 2013] Steganography Browser Extension Status Report
by Hareesan 25 Aug '13

25 Aug '13

Hi, In my previous mail, I was planning to add steganography libraries to the extension. But with the meeting with mentor, we planned to complete the code with proper documentation and to add public key cryptography features. But in my plan, I was able to complete all the UIs and back end framework for all the parts of the extension other than few updates remaining in options page. In cumming weeks, I will be working on completion of code and will add public key cryptography libraries which need some modification from existing libraries. -- Hareesan

1 0

Haskell packages?
by Nikita Karetnikov 23 Aug '13

23 Aug '13

I'd like to improve my Haskell skills. Are there any opportunities? I've been told there is at least one project that uses Haskell, which is not maintained. (For example, this page [1] mentions TorDNSEL, which was replaced by TorBEL.) [1] https://www.torproject.org/getinvolved/volunteer.html.en

5 21

GSOC Status Report - EvilGenius
by Johannes Fürmann 23 Aug '13

23 Aug '13

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello *, During the last two weeks I was primarily busy packing literally everything I own into boxes and unpacking it again, as well as other logistics that have to be done when moving. My equipment as well as my brain and the rest of me should be fully operational again on monday. In spite of the loads of stuff I had to do the last weeks, I still made a few improvement on my projects: * Probe running and logging functionality is now in place * A few improvements on networking: Addresses are now actually set and the corresponding links are pulled up. * Traceroute instrument for debugging purposes. You all have a wonderful weekend ~johannes -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJSF64/AAoJEAgie5o3Q/JpVN4P/00Zbt3l5H0ASF5KBeUE1/7F jTfyDZzYBKr1dV48V4dExkIdud6dtS6gTeaU9gjlrkH/jr6n81Dg4cxJVEH17n2M wrFSN7QiwVOrD/iPfApJhERIT+h3S503ra2Jejg2nnQTwF86Ifcgvr8gMvKus1b5 ddP8nZQSZqY5e+oZBkVUnjvXW4elc7f/XjRmfs6DmwyvTUGYC8Q+B1+bTMEauQU3 9VlY96HzjTzAKqST/7VihVFwToN0T7KK8pIZeH6O6JN7xcrbX2PfjqvRbPrMgrCE PV82yGVLnzX2jJkIbCFjkZZBTZJKd3X8hZ0A6lftko7SKHJBriSl9lEmxRHtq1pP FQVGAB1x/LEDgcaImupXT9IcnY6BJm2mdZ1Le+CPwY3RJq/CdChdxftGDCPqxl62 6yKOYMIUPxE+I9Cw+LZviFOcRCyH9TxOe918fLJeZ/buPViq+Xf1tw9duBHqq/xr OWTZL2qb5fjcJTG5uomGvwi7fOYq3gTHI/1JFlq9abVpUICrns1nEtevwP7RSb7D LyxIm1zsyIzt+8Qgyxh9uVnOrQY6nZiFmAGy8V3KTxIboAr+Z2booF+EgHwroR/g Sn8bcNng6Ln/cvWsU24OoG53/a4stLo5yNMzFj+p/hU5uvYF9R/4/IDJ6SqqqBzR cEOFb9tzJhCZVD5W9rLb =gX0j -----END PGP SIGNATURE-----

1 0

Global semi-passive adversary: suggestion of using expanders
by Paul-Olivier Dehaye 23 Aug '13

23 Aug '13

Hello, Thank you for working on Tor. I have a suggestion and would appreciate input. Please bear with me as I have a limited understanding of the design of Tor and all the different threats that it is meant to mitigate. Below, a (?) indicates a place where I need some confirmation that my understanding is correct, and N indicates either the number of Tor nodes, the number of end-users, or the amount of traffic (I assume these are all linearly related). As far as I can tell, the main threat by a global passive adversary comes from traffic analysis (?). This attack should become easier as the number of Tor nodes increases (?): Tor uses a clique topology, so the number of edges potentially carrying traffic grows like N^2. A dual way to see this is that not enough mixing can happen around a node for incoming/outgoing edge pairs, bar injecting a huge amount of fake traffic. To compensate, it seems natural to look for a sparse yet highly mixing network topology. Mathematically, those are called expanders [1]. A typical example of a family of expanders would be the Erdos-Renyi model [2], and indeed I have found in the literature suggestions for basing anonymizing protocols on such a model. The analysis in the presence of an active adversary becomes very difficult though. Alternatively, one could use a different method for constructing that expander topology, working "all at once". This comes from recent mathematics research (<= 5 years, certainly not my own, see [3]). The graph is then a Cailey graph [4] in a matrix group (the group is fixed and determined by an approximation to the number of Tor nodes, such as nearest third power of a prime number). In some sense this construction interpolates between mixing chains and Tor, and can be seen as a lot of mixing chains interwoven. In the setting of Tor, constructing the Cailey graph would require making two distributed randomize choices: - a matching of elements of the group to Tor nodes (possibly 2:1 for some Tor nodes) - a small subset of generators for the Cailey graph >From my understanding of security protocols, it should be easy to do these two choices safely and fast, as it amounts to choosing a random element in S_N and filling lots of matrix entries with random elements between 1 and a prime p, with some rejection. Once that is done, the network topology is fully determined, and with very high probability gives an expander. This means that traffic gets mixed up in very few hops. The number of hops needed grows as log N, with a constant that can be mitigated by chosing a large generating set above. This is the only downside I see (apart from difficulty to explain the math behind this): the latency would increase, from 3 in the current protocol to maybe 10 or so. I don't know the details of the behaviour of the constants in the last paragraph, and would appreciate feedback from the list before looking too much into this. Paul Dehaye [1] http://en.wikipedia.org/wiki/Expander_graph [2] http://en.wikipedia.org/wiki/Erd%C5%91s%E2%80%93R%C3%A9nyi_model [3] http://terrytao.wordpress.com/2011/12/02/245b-notes-1-basic-theory-of-expan… 15 and remark below [4] http://en.wikipedia.org/wiki/Cayley_graph

4 4

[GSoC 2013] Status report - Searchable metrics archive
by Kostas Jakeliunas 23 Aug '13

23 Aug '13

Hello! Updating on my Searchable Tor metrics archive project. (As is very evident) I'm very open for naming suggestions. :) To the best of my understanding and current satisfaction, I solved the database bottlenecks, or at least I am, as of now, satisfied with the current output from my benchmarking utility. Things may change, but I am confident (and have support to argue) that the whole thing runs swell at least on amazon m2.2xlarge instances. For fun and profit, a part of the database (which, has, for now, status entries (only) in the range [2010-01-01 00:00:00, 2013-05-31 23:00:00]), namely, what is currently used by the Onionoo-like API is now available online (not on EC2, though) - will now write a separate email so that everyone can inspect it. I should now move on with implementing / extending the Onionoo API, in particular, working on date range queries, and refining/rewriting the "list status entries" API point (see below). Need to carefully plan some things, and always keep an updated API document. (Also need to update and publish a separate, more detailed specification document.) More concrete report points: - re-examined my benchmarking approach, and wrote a rather simple but effective set of benchmarking tools (more like a simple script) [1] that can be hopefully used outside this project as well; at the very least, together with the profiling and the query_info tools, it is powerful (but also simple) enough to be used to test all kinds of bottlenecks in ORMs and elsewhere. - used this tool to generate benchmark reports on EC2 and on the (less powerful) dev server, and with different schema settings (usually rather minor schema changes that do not require re-importing all the data) - came up with a triple table schema that proves to render our queries quickly: we first do a search (using whatever criteria (e.g. nickname, fingerprint, address, running), if any) on a table which has a column with unique fingerprints; extract the relevant fingerprints; JOIN with the main status entry table, which is much larger; and get the final results. Benchmarked using this schema. <details> If we are only extracting a list of the latest status entries (with distinct on fingerprint), we can do LIMITs and OFFSETs already on the fingerprint table, before the JOIN. This helps us quite a bit. On the other hand, nickname searches etc. are also efficient. As of now, I have re-enabled nickname+address+fingerprint substring search (not from the middle (LIKE %substring%), but from the beginning of a substring (LIKE substring%), which is still nice), and all is well. Updated the higher-level ORM to reflect this new table [2] (I've yet to change some column names, though - but these are cosmetics.) </details> - found a way to generate the SQL queries that I need to generate using the higher-level SQLAlchemy SQL API using various SQLAlchemy-provided primitives, and always observing the resulting query statements. This is good, because everything becomes more modular: much easier to shape the query depending on the query parameters received, etc. (while still retaining it in sane order.) - hence (re)wrote a part of the Onionoo-like API that uses the new schema and the SQLAlchemy primitives. Extended the API a bit. [3] - wrote a very hacky API point for getting a list of status entries for a given fingerprint. I simply wanted a way (for myself and people) to query this kind of a relation easily and externally. It now works as part of the API. This part will probably need some discussion. - wrote a (kind of a stub) document explaining the current Onionoo-like API, what can be queried, what can be returned, what kinds of parameters work. [4] Will extend this later on. while writing the doc and rewriting part the API, stumbled upon a few things that make clear that I've made some shortcuts that may hurt later on. Will be happy to elaborate on them later on / separately. I need to carefully plan a few things, and then try rewriting the Onionoo API yet again, this time including more parameters and fields returned. TL;DR yay, a working database backend! I might give *one* more update detailing things I might have forgotten about soon re: this report - I don't want to make a habit of delaying reports (which I have consistently done), so reporting what I have now. [1]: https://github.com/wfn/torsearch/blob/master/torsearch/benchmark.py [2]: https://github.com/wfn/torsearch/blob/master/torsearch/models.py [3]: https://github.com/wfn/torsearch/blob/master/torsearch/onionoo_api.py [4]: https://github.com/wfn/torsearch/blob/master/docs/onionoo_api.md -- Kostas (wfn on OFTC) 0x0e5dce45 @ pgp.mit.edu

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev August 2013