- tor-dev - lists.torproject.org

IRC meeting on Wed, Jan 22, 18:00 UTC to discuss next steps for Weather rewrite
by Karsten Loesing 20 Jan '14

20 Jan '14

Hi devs, we're going to have an IRC meeting to discuss next steps for the Weather rewrite: Wednesday, January 22, at 18:00 UTC in #tor-dev on OFTC. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20140122T18 Everyone's invited to join the discussion. Abhiram, Norbert, and Oliver, who all stated their interest in the Weather rewrite, already indicated that they're going to be there. Possible topics are: briefly introduce ourselves, identify open tasks, assign tasks for the next week, talk about infrastructure that would make us more productive, etc. All that shouldn't take longer than 30--45 minutes. If people want to read up on what this is all about, here are two URLs to start with: https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 https://gitweb.torproject.org/weather.git/blob/HEAD:/doc/design.txt Talk to you on Wednesday! All the best, Karsten

1 0

Torsocks 2.0 RC code review
by David Goulet 19 Jan '14

19 Jan '14

Hi everyone, The torsocks 2.0-rc3 code is getting quite stable in my opinion. There are still some issues but nothing feature critical. https://github.com/dgoulet/torsocks I would really love to have help with code review so it can get accepted as a replacement in the near future. Some of you already gave feedbacks so thanks but now it needs the "seal of approval" from the community :). Here are some things you can start with. This new version is built to be thread safe and provides a good compatibility layer for OSes (right now FreeBSD, NetBSD, Linux and OS X are supported). Considering that, you can direct your attention to this: * Synchronization issues (multi threading, reentrancy, ...) * Security obviously :) * Correctness. This is an "inprocess" library thus it has to be bullet proof so it does not crash the application. In src/lib/, every libc call is in its corresponding file matching the man page name like for instance gethostbyname.c contains all reentrant functions and other version of that family as well (gethostbyname_r, gethostbyname2, etc...). Reviewing them just to make sure they mimick as close as possible the libc behaviour. In src/common, connection.c/.h and onion.c/.h are probably the two interfaces that need review. Connection is the one handling new socket and their state where Onion handles the cookies that are sent back to the client (by default: 127.42.42.x) to map an onion address to that cookie once a connection is established (connect()). Other than that, man pages and documentation are also important. You can send patches via email or/and pull request (github or not), I'm easy for contributions! :) Thanks to all! David

3 6

Dusting off dir-spec.txt
by Karsten Loesing 17 Jan '14

17 Jan '14

[Re-sending, because my first attempt apparently got lost somewhere. Apologies if gets found and this is now a duplicate.] Hi devs, hi dir-spec.txt authors, when I reviewed the open proposals related to the directory protocol, I wondered how to integrate the proposed changes into dir-spec.txt. For example, status opinions (proposal 147) are going to add a new variant of the status data format and a new operation that makes authorities produce and exchange opinions at some point in the voting process. I also thought back when I wrote the patch to add microdescriptors to the spec and remembered that I had a hard time finding the right places to add things. So, here's my question: can we reorder a few things in dir-spec.txt to make it easier to read and easier to extend? (To be clear, I'm happy to submit patches for this, I'm just asking if patches are welcome.) In particular, I'd want to start by making the following changes (if you need a table of contents, here's how I generated mine: `grep -Ev "^ |^$|XXXX" dir-spec.txt | less`): Sections 3 ("Formats produced by directory authorities") and 4 ("Directory server operation") apparently started out by separating passive parts (data formats) from active parts (operations). But then 3.4 ("Assigning flags in a vote") and 3.5 ("Computing a consensus from a set of votes") broke this abstraction. One way to fix this would be to move the two mentioned subsections 3.4 and 3.5 to Section 4. Though, personally I'm not a big fan of the passive-active separation, because the description of passive parts implies a lot about how they're going to be used. And then we end up describing things twice, once implicitly and once explicitly. The better fix, IMHO, would be to turn Section 3 into "Directory authority operation and formats" and Section 4 into "Directory cache operation". Section 3 would specify operations in causal order (not sure if this the right term) and specify data formats together with the operation that generates them: - "creating key certificates", - "accepting router descriptors and extra-info documents", - "computing microdescriptors", - "exchanging votes", - "downloading missing certificates", - "downloading router descriptors and extra-info documents", - "computing the consensus", - "computing consensus flavors", - "exchanging detached signatures", and - "publishing the signed consensus". Section 4 would then only contain the subsections from the current Section 4 that are relevant for caches. In cases where cache operations are equivalent or similar to authority operations, there would be a simple reference to the earlier section. Also on the top-level of sections, I'd want to merge Sections 5 ("Client operation: downloading information") and 6 ("Using directory information") into a single section "Client operation". Would you accept patches making these changes? All the best, Karsten

3 12

Re: [tor-dev] Projects to combat/defeat data correlation
by Ximin Luo 17 Jan '14

17 Jan '14

> I imagine the anonymity set would be much smaller for these combined > transports... fewer people using them. In my understanding, the anonymity set doesn't apply to use of PTs since this is only at the entry side. The exit side does not know[1] what PT the originator is using, so is unable to use that information to de-anonymise. [1] at least, in theory should not know, perhaps someone can check there are no side-channels? would be pretty scary if exit could work out that originator is using PTs.

3 2

Re: [tor-dev] Proposal 225: Strawman proposal: commit-and-reveal shared rng
by George Kadianakis 16 Jan '14

16 Jan '14

I'm forwarding a private email by Florian Dold which is related to this discussion. I talked with Florian during CCC and we talked some more over email. Reposting with his permission. Thanks! From: Florian Dold <dold(a)in.tum.de> Date: Sat, 4 Jan 2014 20:45:15 +0100 To: George Kadianakis <desnacked(a)riseup.net> > > Hi! > > I'm afraid there is not much usable information in the slides, it's > just a quick overview of what I'm currently implementing for GNUnet > ... > > However, I do have some comments / ideas for the distributed nonce > generation in Tor. From what I read, most of your current efforts > focus on protocols for distributed *key* generation, which might be > overkill, as your scenario needs less structure --- only a random > value, not a key pair must be generated. > > There's been a lot of theoretical discussion about that in literature > about exactly that, usually under the name "Collective Coin Flipping" > or "Leader Election" (which also must generate a random number), and I > think these ideas are more appropriate for your problem than those > from DKG. > > Let me sketch how their protocols (see [1], [2] and many many more) > work. For simplicity, let's only generate single bit: > > 1. Each player P_i broadcasts a boolean b_i. > 2. The resulting random bit is f(b_1,...,b_n) > > Now, when f = XOR, this corresponds exactly to the protocol we > discussed, which is not secure against adaptive adversaries. However, > when choosing f as the majority function > > f(b_1,...,b_n) = 1 if sum(b_1,...,b_n) > ceil(n/2), 0 otherwise > > it won't be as easy for a single player (or even a small coalition) to > influence the resulting bit (as there's a chance that their choices > don't even influence the final result). > > There are constructions for the function 'f' in literature that are > even more influence-resilient than the majority function. > > > But of course, this is only part of the issue: Problems arise when > players don't broadcast their values correctly. This essentially > boils down to the byzantine consensus problem, and there are various > approaches to this. One of the simplest implementations of this are > based on gradecast [3], a multicast protocol that also gives a > "confidence level" for the correctness of the broadcast. There are > many optimizations of gradecast, including some probablistic > constructions for settings with a large number of players. > > The last paragraph, however, also might apply to distributed key > generation that do *not* use the Fouque-protocol with its complex > zero-knowledge proofs of fair encryption to avoid private channels. > > > Does this help? While still somewhat complex, the collective coin > flipping protocols are probably still less complex than establishing a > distributed key and then doing threshold elgamal, as proposed by > Nicholas Hopper. > > Happy Hacking! > Florian > > [1] http://www.cs.huji.ac.il/~nati/PAPERS/coll_coin_fl.pdf > [2] www.cs.yale.edu/homes/aspnes/papers/stoc97-proceedings.pdf > [3] http://arxiv.org/abs/1007.1049 > > On Sat, Jan 4, 2014 at 6:38 PM, George Kadianakis <desnacked(a)riseup.net> wrote: > > Hey there, > > > > I'm the guy that talked with you about Distributed Key Agreements in CCC. > > We talked about its applications in Tor (we need Distributed Nonce > > Agreement) and attacks on the naive commit-and-reveal method. > > > > I was wondering if your slides or talk is uploaded somewhere on the > > Internet. I found > > https://gnunet.org/content/video-30c3-talk-gnu-name-system but it doesn't > > seem to be the one I was looking for. > > > > Thank you! > > > > [BTW, the relevant Tor ticket is: > > https://trac.torproject.org/projects/tor/ticket/8244 > > and the threshold elgamal idea is here: > > https://lists.torproject.org/pipermail/tor-dev/2013-December/005944.html ] > > > >

2 1

Re: [tor-dev] Projects to combat/defeat data correlation
by Malard Joel 16 Jan '14

16 Jan '14

Sounds like a challenging problem, good luck. In the case of the Harvard exam, the administration may have used some meta data that may not be under your control, listing out all student taking an exam that day, asking teachers for a shortlist of their class jerks and clowns, checking for repeat offenders, finding which ones had downloaded TOR software, asking frat buddies and classmates. Someone willing to send a bomb threat just to avoid an exam may be more likely to brag after the fact, etc. Cheers, Joel ------------------------------ On Wed, Jan 15, 2014 7:16 PM PST Jim Rucker wrote: >There was a story in the news recently of a Harvard student who used Tor to >send a bomb threat to Harvard in order to cancel classes so he wouldn't >have to take a test. He was apprehended within a day, which puts into >question the anonymity of Tor. > >From my understanding (please correct me if I'm wrong) Tor has a weakness >in that if someone can monitor data going into the relays and going out of >the exit nodes then they can defeat the anonymity of tor by correlating the >size and number of packets being sent to relays and comparing those that >the packets leaving the exit nodes. > >Are there any projects in Tor being worked in to combat data correlation? >For instance, relays the send/recv constant data rates continuously - >capping data rates and padding partial or non-packets with random data to >maintain the data rates

1 0

Re: [tor-dev] Anyone wanting to write some Weather-tight code?
by Abhiram Chintangal 16 Jan '14

16 Jan '14

Hello Norbert and Karsten, I have added a couple of attachments to the projects wiki-page. The first one, is a UML diagram of the data-models being used in the current weather. It should gives us a good idea about the current implementation. The second attachment is the Design Document from the current Tor Weather application. It should give a decent idea about the important modules in the application and more importantly its work-flow. Thanks!

1 0

Anyone wanting to write some Weather-tight code?
by Oliver Baumann 15 Jan '14

15 Jan '14

Hi guys, just like Norbert, I have wanted to become an active contributor for some time and this fledgling project seems like a nice chance. If you're in need of a frontend-guy with some Python background, I'll happily add myself to the wiki and chip in wherever I can! All the best, Oliver -- PGP: 0x520AADF9 --

2 1

Re: [tor-dev] Anyone wanting to write some Weather-tight code?
by abhiram 15 Jan '14

15 Jan '14

Hello Karsten, It looks like a nice little project to work on. I reguarly check my relay-status via Atlas, at the moment using the Onionoo service makes sense to me too. For now the onionoo-glue-code, seems like a good place to start. Do you have any other suggestions or ideas? thanks! On Thu, Jan 9, 2014 at 2:11 PM, Karsten Loesing <karsten(a)torproject.org>wrote: > Hello coders, > > is anyone here looking for a fun new project to hack on? Here's > something you could do to help grow the Tor network: > > We're planning to decommission the currently unmaintained Tor Weather > which provides an email notification service to any users who want to > monitor the status of a Tor node. And we'd like to replace it with a > clean rewrite of this service. > > https://weather.torproject.org/ > > (You're asking why we're not simply trying to find a new maintainer? > That's also an option, but a clean rewrite that uses the Onionoo service > would be much smaller and easier to maintain in the future. Read on to > find out more.) > > Here's what the rewritten Weather should do: > > - Maintain a list of subscriptions, consisting of an email address, a > password, a relay identity fingerprint, how soon the user wants to be > notified of problems, when it was last notified, etc. > > - Allow users to create, read, update, and delete subscriptions via a > web interface. All these operations should have the usual security > features like email address verification, password login, etc. > > - Allow users to search for relays to subscribe for by relay IP address, > relay identity fingerprint, or relay nickname. This search can be done > with help of Onionoo's search feature, or by simply adding a link to > Atlas (https://atlas.torproject.org/) or Globe > (https://globe.torproject.org/) > > - Once per hour, download a list from Onionoo that contains relays that > have been running in the last week. Check if there are any relays that > have been offline for long enough to notify a subscribed user. Send out > emails. > > - Once per day, download bandwidth histories of relays from Onionoo and > check whether a relay has been running long enough and fast enough that > the operator should be offered a t-shirt. Send out emails, regardless > of subscriptions, and ask if operators would want one. > > As you can see, most of the work can be done with help of Onionoo. The > parts that need to be written are a web and an email interface, a small > database for subscriptions, and some glue code to talk to Onionoo. > > (And if you still favor the variant where somebody maintains the current > Weather, be aware that it needs to parse Tor descriptors and keep its > own relay database to do searches, to check how long relays are offline, > and to decide which relay operators should get a t-shirt.) > > Here's some more information on the Onionoo service: > > https://onionoo.torproject.org/ > > Happy to provide more information! > > All the best, > Karsten > _______________________________________________ > tor-dev mailing list > tor-dev(a)lists.torproject.org > https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev > -- Abhiram Chintangal Graduate Student Florida State University Computer Science Department (850) 980-4954

6 14

Some uncommon use cases for PT library transport selection
by David Fifield 13 Jan '14

13 Jan '14

I've been thinking about a couple of tricky use cases for pluggable transport libraries, and whether we should do anything to try to support them. The first use case is the flashproxy/websocket use case. flashproxy-client recognizes the two transport names "flashproxy" and "websocket" as synonyms. That is, tor can ask for either one and they will work equivalently. But what should happen when tor asks for "*"; i.e., the activation of all supported transports? We want to start only one SOCKS listener, for the preferred name "flashproxy", not a separate listener for every synonym. The way that you would indicate you support two transport names would be done like this in pyptlib and goptlib respectively: ptclient.init(["flashproxy", "websocket"]) ptInfo, err := pt.ClientSetup([]string{"flashproxy", "websocket"}) but neither of those work for this use case, because if tor asks for "*", you get two listeners. Maybe we don't care about this use case, because as I understand it, tor will never ask for "*" anyway. The second use case is the fog* use case. As a server, we may not want to declare all the transports we support in advance. Rather, we may prefer to look at the names of the transports tor has asked for, and decide for each one whether we support it. The idea here is that since we can arbitrarily chain a set of transports, we can't just enumerate all possible chains and declare those as the transport we support. Both pylib and goptlib require you to list all the transports you want to support on initialization. We would like for tor to be able to ask for a transport name like "obfs3|cbr|obfs3|websocket", and we check to see whether we are able to construct such a chain. The current idea is to only support a small number of predefined chains in a configuration file, so that we can in fact declare them all in advance. https://trac.torproject.org/projects/tor/ticket/9744 David Fifield * fog is the transport combinator formerly known as Metallica; see https://trac.torproject.org/projects/tor/ticket/9743.

1 1