- tor-dev - lists.torproject.org

(no subject)
by Gareth Owen 01 Jul '14

01 Jul '14

Dear all I'm working on a tor research project and am having difficulty understanding the SENDME cells. The tor spec acknowledges that it isn't particularly clear so I would welcome some clarification please. The spec says that *all* nodes in a circuit maintain a send and receive window, and that this window is decremented on each RELAY_DATA and incremented on each SENDME. Cells that are neither of these do not affect the window size. The problem I have understanding is, that only edge nodes will know whether a cell is a RELAY_DATA, the intermediate nodes only know that its a RELAY but not what type. So, if only RELAY_DATA decrements the window size, and intermediate nodes cannot spot these, what point is there in intermediate nodes having a window? Any help greatly appreciated. Gareth --- Dr Gareth Owen Senior Lecturer School of Computing, University of Portsmouth W: ghowen.me

1 0

Re: [tor-dev] I have a group at internet archive that are, interested in buying a lot of OnionPi's
by Virgil Griffith 01 Jul '14

01 Jul '14

It's already established that, for clients, onion-pi's are discouraged---onion-pi wifi doesn't protect enough (I.e., at all) from browser-based attacks. Given that, The question is now, "Are onion-pi's are good enough to be useful relays?" Roger said no. Is there a more informed opinion on this matter---particularly from someone who has actually tried this? Are there any relays that are known to run on onion-pi? If an onion-pi is insufficient for a useful Tor relay, what is the limiting reagent? What more does it need to be useful? -V

2 1

Disk full under .tor
by grarpamp 30 Jun '14

30 Jun '14

Tor seems to have kept running ok through at least one disk full instance here. Posting in case such rare edge conditions haven't yet been fully 'do the right thinged' in design. cached-consensus": No space left on device cached-descriptors.new": No space left on device Unable to store router descriptor

1 0

I have a group at internet archive that are interested in buying a lot of OnionPi's
by Virgil Griffith 29 Jun '14

29 Jun '14

What is the current state of the art on this, and if it is ready for larger deployment want to buy about 50-100 of them. -V

5 4

Re: [tor-dev] I have a group at internet archive that are, interested in buying a lot of OnionPi's
by Rémi 29 Jun '14

29 Jun '14

Roger wrote: > And the onionpi boxes don't have enough cpu to be a useful relay. I'm not sure what the definition of 'useful relay' is, but I am running an exit relay with 900KB/s and between 1000-1500 consensus weight. This is the limit for the pi, but definitively above the 100KB/s I read somewhere else. Also, although I know it is nowhere near decent security, I do get a warm feeling from the fact that all my non-tor home traffic gets mixed/emitted along with tor exit traffic. I'm not running an onionpi because I prefer TorBrowser for all the good reasons, but the pi makes a nice little relay I think. R.

1 0

Proposal for improving social incentives for relay operators
by Virgil Griffith 29 Jun '14

29 Jun '14

For a while I've been seeking to grow the Tor network in both size and goodput. Towards this end, I've explored various avenues such as increasing user-awareness via tor2web. More recently, I've been exploring financial incentives like TorCoin. Not wanting to strictly limit ourselves to financial incentives, I began reading the literature on incentivizing volunteers. The most relevant papers I found are: * http://www-2.rotman.utoronto.ca/facbios/file/LMS2_ManSci-Paper-Final.pdf * http://pareto.uab.es/~prey/gneezy_254.pdf * https://dl.dropboxusercontent.com/u/3308162/Slonim%202013.pdf The most relevant of these papers (Lacetera 2013) cites the major motivations for volunteer labor are: "pure altruism, warm glow, self-image, and reputation". Upon reading this I realized TorCoin's technical interestingness had blinded me to much easier to leverage motivations of "warm glow" and "reputation". I propose the following system for harnessing "warm glow" and "reputation" for Tor relay operators. I am willing to fund this in its entirety. I propose establishing a subdomain on torproject.org giving each Tor relay operator (hereafter affectionately called "Torati") his/her own page using the information her machines provide to the Tor Directory Consensus. The fields to show on her "Torati profile page" would be things like: ContactInfo, PGP fingerprint, list of server nicknames, date the Directory Authorities first saw her contact info, etc. You can also imagine a receiving special "special recognition stars" for operating an exit or bridge node. Moreover, some bandwidth measurement like EigenSpeed or TorCoin gain traction, the Torati page could recognize contributors with by listing the sum total she has relayed to the Tor network. Naturally a node can opt-out of Torati recognition by setting a parameter in the torrc file. I argue this would be a cheap and easy way to motivate operators to volunteer more bandwidth for the Tor network. As mentioned before, I am willing to fund this in its entirety. -Virgil

8 10

[PATCH] remove test for remote SOCKS Port at config validation
by Martin Kepplinger 28 Jun '14

28 Jun '14

remove the check for a non-local SOCKS Port in the config by removing the flag when calling parse_port_config() for it. this should only prevent parse_port_config() from writing a warning that is written when the listener is opened anyways, according to https://trac.torproject.org/projects/tor/ticket/4019 --- this is UNTESTED and more of a question if that may suffice for closing ticket 4019 for now. src/or/config.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/or/config.c b/src/or/config.c index 10df839..7c22171 100644 --- a/src/or/config.c +++ b/src/or/config.c @@ -6002,8 +6002,7 @@ parse_ports(or_options_t *options, int validate_only, options->SocksPort_lines, options->SocksListenAddress, "Socks", CONN_TYPE_AP_LISTENER, "127.0.0.1", 9050, - CL_PORT_WARN_NONLOCAL|CL_PORT_ALLOW_EXTRA_LISTENADDR| - CL_PORT_TAKES_HOSTNAMES) < 0) { + CL_PORT_ALLOW_EXTRA_LISTENADDR|CL_PORT_TAKES_HOSTNAMES) < 0) { *msg = tor_strdup("Invalid SocksPort/SocksListenAddress configuration"); goto err; } -- 1.7.10.4

1 0

PrivEX - Privacy
by Tariq Elahi 27 Jun '14

27 Jun '14

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 . 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. Please don't hesitate to give us your feedback, either to the list or to me via email. Cheers, Tariq

3 4

Who shall we send to the GSoC reunion?
by Amogh Pradeep 25 Jun '14

25 Jun '14

Well, questions pretty straightforward, and I didn't get selected via the lucky draw, so I was thinking of alternative ways to get there!

1 0

Fwd: Run a Small Tor Network for a Research
by Soroosh Sardari 25 Jun '14

25 Jun '14

Hi I want to run a small tor network with only 3 node, entry, router, and exit node. Also I want to set this three nodes in the client node without using directory server. Any idea appreciated. Regards, Soroosh

3 2