[tor-dev] Running Tor with static path
Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i need to determine the IPs and keys of ORs in OP permanently. Is there any idea of what function of Tor's code should be replace?! Thanks a lot ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Running Tor with static path
On Mon, Jun 16, 2014 at 11:38 AM, mahdi mahdi.it2...@gmail.com wrote: Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i need to determine the IPs and keys of ORs in OP permanently. Is there any idea of what function of Tor's code should be replace?! You can do this using a custom controller; you don't need to modify the Tor program itself. There's a library for writing controllers here: https://stem.torproject.org/ ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Running Tor with static path
On Mon, 2014-06-16 at 20:08 +0430, mahdi wrote: Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i need to determine the IPs and keys of ORs in OP permanently. Is there any idea of what function of Tor's code should be replace?! To fix the entry and exit nodes you can just use the EntryNodes (or Bridges), ExitNodes, and StrictNodes configuration options. To fix the middle relay you need to change some code (I think). The relevant functions should be circuitbuild.c:circuit_establish_circuit() and the functions it calls, especially circuitbuild.c:choose_good_middle_server(). --ll signature.asc Description: This is a digitally signed message part ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] Running Tor with static path
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 16/06/14 17:47, Zack Weinberg wrote: On Mon, Jun 16, 2014 at 11:38 AM, mahdi mahdi.it2...@gmail.com wrote: Hi all, I want to execute an experiment on Tor in which i need to fix the ip address of entry,relay and exit onion router. For that i need to determine the IPs and keys of ORs in OP permanently. Is there any idea of what function of Tor's code should be replace?! You can do this using a custom controller; you don't need to modify the Tor program itself. There's a library for writing controllers here: https://stem.torproject.org/ A related question: is it possible to build introduction/rendezvous circuits via the controller protocol? Cheers, Michael -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJTnyZcAAoJEBEET9GfxSfMDZwH/iEU+zbvMMM5AEl79UUwNQXU H9WXBIllls1Ofc0PUbkaZHyoP2ekRxNexDGxaEfDyPEb3HVpxMjVkWo9wB5wGE9q +kcQ7oneSrdEW3ba6bJOCxkby0HkNXEUqVHsINdGF5gEkaKcxoYyPZRFsgi+yitL oMfXv/O1Bv5+f1qAdBbq3VkbAY1NuPbe8W96yFeSTa9yVIDV5k6l1bYkIwfCdFE2 QURgE57eaDsRg9JUNiYJEWHjf3uVYvUvaA0r9iqr+Wk3daB33CJQb65BYXVwRraE vcONOAl3Zfqiemg4nbjOug0qKsKRPhqh8mtry0tQTJTFhpFQ68DGf6/KOyUKnao= =+jjD -END PGP SIGNATURE- ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PrivEX - Privacy
Tariq Elahi: What we would really like in order of importance is 1) a design review of our proposal, […] Maybe it's a non-issue but “better ask than sorry”. If I get it, the idea is to publish a list of visited domain names and how frequently they have been visited (with noise). Would the privacy of users be respected if a website contains a link to a per-visitor generated hostname (using DNS wildcards)? -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PrivEX - Privacy
Lunar: Tariq Elahi: What we would really like in order of importance is 1) a design review of our proposal, […] Maybe it's a non-issue but “better ask than sorry”. If I get it, the idea is to publish a list of visited domain names and how frequently they have been visited (with noise). Would the privacy of users be respected if a website contains a link to a per-visitor generated hostname (using DNS wildcards)? Please ignore me: “To further reduce the risk of inadvertent disclosures, it collects only information about destinations that appear in a list of known censored websites.” -- Lunar lu...@torproject.org signature.asc Description: Digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] lcov test coverage reports
On Mon, Jun 16, 2014 at 10:55 AM, Nick Mathewson ni...@freehaven.net wrote: [...] Additionally, one thing that I'd really love to see -- though I don't at all know whether lcov can do this as it stands -- is a semantic diff between two coverage outputs. When writing new unit tests at random, or when checking functions that you know need coverage, it's useful to ask Which lines are not covered? But for validating new code and checking patches, the question I want to ask is Which *new* or *changed* lines are not covered? We kinda have a script for this now, but learning to read its outputs is not as easy as I'd like. It would appear at first glance that you can do something *almost* like this using lcov --diff and genhtml --highlight. Those options together seem to be able to let you know about lines that used to be covered but which are no longer covered. (I'm hoping to learn about likes that changed or started to exist which are uncovered.) ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
Re: [tor-dev] PrivEX - Privacy
On 11/06/14 20:54, Tariq Elahi wrote: tl;dr: We propose collecting data from exit nodes to improve the Tor network, using differential privacy and secure multiparty computation to do it in a privacy-sensitive manner. Hi tor-dev, In the ongoing effort to make Tor faster, secure and more resilient, network data plays an important role. If we know how the network is being used, what its clients' needs are and the threats that it faces we can deal with these in an intelligent manner. While the Tor Project does collect some statistics from guards, it does not currently collect and share potentially sensitive exit statistics. This data includes destination statistics and client timing behaviour, among many other potentially interesting, but privacy sensitive, data points. This reticence to collect data is due to the (well-founded) risk to clients and OR operators that this data could pose, such as correlation and coercion attacks. This is unfortunate since, as we observe above, in order to make improvements to the Tor network and its feature set, it would be beneficial to know what is going on inside it and with its users. To that end, it would be great if we were able to learn about network and client trend data. Some concrete examples include circuit-level data volumes, guard traffic usage, lengths of internal buffers, and latencies at relays. Indeed, if it can be counted then we should be able to collect and report it in a privacy-preserving manner. Which brings me to the reason for this email; I have had the good fortune to work with George Danezis at UCL and my supervisor Ian Goldberg at the University of Waterloo on coming up with a solution to this private data collection problem. We have created a system, PrivEx, that uses modern privacy-preserving techniques such as differential privacy and secure multiparty computation to address this thorny set of challenges; we have written up the details in a tech report that can be found here:http://cacr.uwaterloo.ca/techreports/2014/cacr2014-08.pdf . First of all, thanks for doing this research! Having such a system in place would be very useful. If it can be done securely. I don't feel competent enough to review the crypto parts in that report, so I'll have to leave that to others on this list. Just one question from taking a quick look over the report: how resilient are the two designs to failing tally key servers? It seems that the plan is to have around 10 of those, which is about the number of directory authorities. And even those are sometimes having difficulty producing a consensus every hour. We even have a dedicated service that watches out for problems with the consensus process. So, what if a subset of the tally key servers break temporarily or even permanently? I guess what I'm asking is how much coordination effort does it take to run your system? Would we need a new tally-key-server-health service? We have also created implementations of the two variants of PrivEx as described in the tech report. We are currently putting in the finishing touches and will be releasing them soon as open source in a git repo. We would like to start by rolling out our own PrivEx-enabled exits in the Tor network and begin collecting destination visit statistics. We expect that PrivEx will be generally useful to all exit operators and the Tor network in general but there is no requirement to deploy it everywhere. We hope to deploy PrivEx on a handful of exits during the June-August timeframe. What we would really like in order of importance is 1) a design review of our proposal, 2) an implementation review would be nice (once we release it). We hope that these reviews will address the main concerns of the community at large as well as give it, and us, a measure of confidence that collecting data with PrivEx is inherently good and is being done in a responsible and intelligent manner. We anticipate that this would make PrivEx an attractive addition for the Tor Project and their data collection needs. What's the timeline here? You say that the code will be released soon, that you hope to deploy exits during the June-August timeframe, and that you're hoping to get some review on design and implementation. In what order will these things happen? Stated differently: will people have sufficient time to look out for implementation flaws before you deploy your exits? Please don't hesitate to give us your feedback, either to the list or to me via email. Thanks for announcing your plans here in advance! All the best, Karsten ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
[tor-dev] ANN: OnionPy 0.1.5
Hello all, my OnionOO python wrapper has now matured significantly. While I was gone for around a month due to being otherwise occupied, I have now given OnionPy a lot of polish. The new features: - Python2 compatibility (All it took for that was to change the readme) - Encapsulated caching layer that includes a memcached interface as well as a simple python dict caching mechanism, or you can add glue code for your favourite caching backend yourself - It's on Pypi! [1] - Extended test / demonstration script Many thanks to meejah for his help. If you are planning to make something in python that uses the tor network status, accessing OnionOO [2] using OnionPy might be exactly what you need. If you are interested, check out the repo and readme! [3] Of course, criticism, suggestions, and pull requests are always welcome. Best regards, Luke [1] https://pypi.python.org/pypi/OnionPy [2] https://onionoo.torproject.org/ [3] https://github.com/duk3luk3/onion-py signature.asc Description: OpenPGP digital signature ___ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
