- tor-dev - lists.torproject.org

Tor bufferbloat
by David Goulet 05 Sep '12

05 Sep '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi everyone, I discovered, during a presentation at this year LinuxCon in San Diego, the problem of "bufferbloat" which is encountered in network bottlenecks. https://en.wikipedia.org/wiki/Bufferbloat http://www.bufferbloat.net/ There is been a good amount of work done so far to fix this problem ending up with the CoDel algorithm (http://queue.acm.org/detail.cfm?id=2209336) The Linux kernel is about to accept this policy as default. Anyhow, I looked around for some recent studies on the Tor network about such congestion issues but I can't find any information on if this phenomenon is observed on the Tor network. Someone knows about that? Thanks a lot! David -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJQR59ZAAoJEELoaioR9I02nkkH/0NYYnaca6N5pbDDbu96klff BGVmxcO8TEbbdI41HBWaJJHyUSi1CDbfZXcK6eaqRgDhj/yGcTN4YKgU/fP7LQFw /rp+MnWxPt7uqfrso+jSgvpDX6FS8r9cXwG6aMd9V39CuLRoVHYnNAMQrwHMyXud bMk0cHe71FGcyW+BGxZwrbjtvP3gcIZH9r/LNGaJepRzn+vB0NcwVpUG08D50Nxe M/3Lhokrc/IqaFi0+FX5fUoc8TALsjgjPZ672DdsY1CMwxbPMxpBKadJ9TWA906U QNxZb/lOa/fSWrnjY3nDaFJNppmyqYgoC1iJNJiCiJC8Jbxgj0/gyQjhY1d11Qc= =yFyg -----END PGP SIGNATURE-----

2 1

Damian's Status Report - August 2012
by Damian Johnson 04 Sep '12

04 Sep '12

Hi all. I spent most of August, like the prior month, traveling. This time I attended Toorcamp [1] and went on vacation. Both were pleasant and relaxing, but not terribly conducive to coding so I don't have much to report... * Descriptor CSV Export Functionality Naif proposed export functionality for Tor server descriptors a while back [1], which Eric and Megan took the first stab at [2]. I ended up revising this quite a bit [4], but it turned out nicely. * Caching Expansion and Test Prompt Added caching for GETCONF and static GETINFO queries. I also added a handy little script for a debugging interpretor. It kicks off Tor, then provides an interactive python prompt with a controller instance to it (optionally shutting Tor down afterward). Ravi code reviewed these changes [5] and volunteered to do code reviews of my future work as well. * Consensus Parsing Over the last few weeks Ravi's been working on a patch to parse network status documents [6]. It's functional, but missing unit tests and deviates from the parsing style and strict validation done for the other descriptor types so I'm taking a turn with the code. Thus far I'm done revising and adding tests for router status entries, and now working on the document. Changes are available in the 'document-parsing' branch of my repo [7]. Parsing these documents is a far larger task than I thought (especially if you include v2 documents and microdescriptors), so working on this branch will probably keep me occupied for much of September. * Controller Expansion Ravi has gone on a hacking binge, adding support for USEFEATURE [8], SIGNAL [9], EXTENDCIRCUIT [10], and SETCIRCUITPURPOSE [11]. Cheers! -Damian [1] http://www.toorcamp.org/ [2] https://trac.torproject.org/6171 [3] https://trac.torproject.org/6512 [4] https://gitweb.torproject.org/stem.git/commitdiff/7022021c4207a0066cb932616… [5] https://trac.torproject.org/6631 [6] https://trac.torproject.org/6569 [7] https://gitweb.torproject.org/user/atagar/stem.git/shortlog/refs/heads/docu… [8] https://trac.torproject.org/6417 [9] https://trac.torproject.org/6659 [10] https://trac.torproject.org/6666 [11] https://trac.torproject.org/6670

1 0

Tor on IPv6 roadmap and status page
by Linus Nordberg 02 Sep '12

02 Sep '12

Hi, The roadmaps/Tor/IPv6 [1] wiki page has been started with the goal of communicating the status of the work with Tor on IPv6. Additionally, searching for Trac tickets with the keyword "ipv6" [2] might give a picture of what's going on. Asking here or highlighting ln5 on #tor-dev is of course another perfectly fine option. [1] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 [2] https://trac.torproject.org/projects/tor/query?keywords=~ipv6 -- Linus

4 5

Linus' August 2012 status report
by Linus Nordberg 01 Sep '12

01 Sep '12

Hi, What happened in August. Got most of #4564 working and parts of it merged to master, including - Directory authorities vote for IPv6 public relays (micro descriptors not yet merged) - Relays bind to and publish IPv6 addresses - Clients use IPv6 relays in consensus (not using micro descriptors) Created an IPv6 status and road map page roadmaps/Tor/IPv6 [1]. Tickets worked on include 4455, 4620, 5535, 6362, 6363, 6364, 6423, 6514, 6621. Made an interview for the Swedish paper Ny Teknik. What's happening in September. September is the month of getting Tor on IPv6 deployed! Primarily the client to non-private bridges parts and hopefully also client to relays. See above mentioned IPv6 road map page [1] for details. [1] https://trac.torproject.org/projects/tor/wiki/org/roadmaps/Tor/IPv6 -- Linus

1 0

Karsten's status report August 1--31
by Karsten Loesing 01 Sep '12

01 Sep '12

Hi everyone, August was a long month for me, and I feel like I spent more time reviewing other people's code than writing my own. That's really cool! We have a bunch of new metrics-related code now, and I hope there will be even more code contributions for me to review next month! So, below is what I did in August. Compared to last month's report, I left out how much of my developer time I spent on these tasks and added more links instead. Best, Karsten Added three new graphs to the metrics website: the first two graphs show our progress in operating 125 fast exits [1] (first half of #6498), which is a deliverable for sponsor J [2]; the third graph shows advertised bandwidth and bandwidth history by relay flags [3] (#6671). Also fixed problems with cutting off enough days from graphs for which we don't have enough data yet (#6593) and removed GetTor graphs and related code to reduce future maintenance effort (#6395). The gentle reader may have noticed that there was no mention of code reviewing in the paragraph above, but just own code writing. That's correct, the metrics website is still a one-man show. I'm planning to split up the metrics website beast into a component that produces JSON-formatted graph data [4] and ask other people to write components visualizing the data, like Walter Kim's metrics website prototype [5]. Hopefully there will be more code contributions if people don't have to mess with Java servlets in the current metrics website code. Reviewed Sathya's great contributions to what we're now calling Compass [6]. Compass is a website and command-line tool to filter the set of currently running relays and group by same country or same AS. It was originally written by delber to analyze Tor network diversity. Sathya improved Compass by adding options to show only fast exits and almost fast exits for the sponsor J project to add 125 fast exits [2], and he wrote the website part. Since Compass went live, we had a lot of tickets opened by cypherpunks that we're almost unable to handle [7]. Patches welcome, Sathya and I will review them! Improved graphs in Atlas [8] to show the displayed quantity on the y axis (#5388) and added graphs on various probabilities to be selected by clients (#5455). Arturo reviewed and cleaned up these patches. Speaking of code contributions, there are quite a few open tickets [9] that would benefit from JavaScript developers wanting to help out! Reviewed Pyonionoo [10], the Wesleyan students' Python rewrite of Onionoo, the data provider behind Compass and Atlas. More precisely, they were working on the front-end portion of Onionoo which gives out JSON-formatted data, not on the number-crunching back-end that Sathya is about to rewrite in Python (#6452). Basic functionality of Pyonionoo works, but there are a few defects (#6707, #6708) and one enhancement (#6709) that we'll have to work on before deploying it. Of course, we have more open tickets for the Java and/or Python Onionoo [11]. Converted even more old tech reports into the new Tor Tech Report format [12] (#5405). The goal here is to have a single place for all reports we produce and that other researchers can use to cite our work. Set up Rob's Tor simulator Shadow [13] to see if there are any usability issues that would prevent researchers from using it. Turns out it's not just a very powerful tool to evaluate changes to the Tor code, but also doesn't require its users to be rocket scientists. I'm planning to play more with Shadow in September and walk through the instructions in Shadow's wiki [14] to find any remaining pitfalls. And then I'll encourage Roger and Rob to blog about Shadow. [1] https://metrics.torproject.org/fast-exits.html [2] https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorJ [3] https://metrics.torproject.org/network.html#bandwidth-flags [4] https://metrics.torproject.org/graphs/relays-by-country [5] http://tigerpa.ws/tor_metrics/ [6] https://compass.torproject.org/ [7] https://trac.torproject.org/projects/tor/query?component=Compass&status=!cl… [8] https://atlas.torproject.org/#details/D223399907113A1F216AAA64997BC1D4CFA8E… [9] https://trac.torproject.org/projects/tor/query?component=Atlas&status=!clos… [10] https://gitweb.torproject.org/pyonionoo.git [11] https://trac.torproject.org/projects/tor/query?component=Onionoo&status=!cl… [12] https://research.torproject.org/techreports.html [13] http://shadow.cs.umn.edu/ [14] https://github.com/shadow/shadow/wiki

1 0

Nick's August 2012 status report
by Nick Mathewson 01 Sep '12

01 Sep '12

THINGS I DID IN AUGUST I spent a few days vacationing with my family in Maine; took a day off for my birthday, and generally chilled out. I merged lots of bugfixes and patches -- some mine, some other people's, some requiring rewriting and review, some not. This included some security-related stuff that lost me a little sleep. It also involved hacking on some neat patches from Stewart Smith (with help from Jim Meyering) to revamp our build system. We put out a new 0.2.2. I fixed the more important (fixable) bugs in 0.2.3 (notably 6507 and 6244 and 6404), and pushed back on some others. IMO we're now ready to release the (probably) last 0.2.3.x-rc. I merged more patches into 0.2.4; see the new changes files there for more info. Lots of these were ipv6-related stuff from Linus. I started a draft for BEGIN2 cells so I can try to get a more future-proof IPv6 protocol implementation. This is blocked while I teach myself how DNSSEC works once and for all. I tried to get a little more testing on alternatives to our current (bogus, deteriorating) geoip supplier (see #6266) but didn't get anything beyond my older inconclusive results. I started working on an implementation for proposal 200, and a revised 202. With help from some libevent users, I fixed an SSL bug that might have been one of the (probably several) things making SSL bufferevents unstable. The fix appears in libevent 2.0.20-stable. I agreed to fly out to SF to accept the EFF's pioneer awards on Tor's behalf. I had an anniversary and a birthday. I proposed a crazy idea about a separate 0.2.3.x branch for DAs. I chatted a little about metaformats, and spent a while catching up on the ones I didn't know the details of. Currently I'm thinking YAML is a hot mess, and ProtocolBuffers is not too bad actually. There was this insane stegotorus bug that I sort of tracked down. That is, I can tell you which libevent commit to revert in order to make the problem go away (that is, 3467f2fa3bbff0dab6865), but I can't for the life of me figure out what's wrong with it. My current guess is that it provokes an issue somewhere else. A couple of friends/acquaintances approached me about working for Tor as a project manager. I told them to email jobs(a)torproject.org. I don't think we've heard from them yet. It would rock if we had a faster release schedule. I've been trying to find projects our size that do it right. This coming month I must help Linus get our September IPv6 deliverables deployed. I need to help Andrea get her refactored channel abstraction merged, and make sure she's got more stuff to do (and more interesting stuff to do!) as she transitions to full-time. I must get that blog post I'm cowriting with Steven finished, and our paper for November started. And I need to write some of my own code too. I also need to finalize a plan and a schedule for 0.2.4 and send them to the world. "when in danger or in doubt," -- Nick

1 0

[GSoC] [Stegotorus] Recent activities
by vmon 31 Aug '12

31 Aug '12

Hey Zack, I know you are super busy packing for your big move, but I thought as tomorrow is the hard deadline for GSoC, is not a bad ideas to give you some final update. So most of last week I spent on the conflict that occurred between libcurl and libevent having their eyes on the same socket. I tried different ugly and uglier solutions but finally settled on this one which is not that bad: http://stackoverflow.com/questions/12021217/how-to-ask-libcurl-not-to-liste… After that, I'm passing all time line tests now. However, when I look at the client log, I see that some of the sequence no are missing in the recv: like this 203.7169 [debug] recv: <3.81> receiving block 42 <d=0 p=9 f=DAT> T:203.7170: ckt 3 <ntp 1 outq 0>: recv 42 <d=0 p=9 f=DAT> and the next recv is like this: 203.7926 [debug] recv: <3.99> receiving block 60 <d=0 p=1 f=DAT> T:203.7927: ckt 3 <ntp 1 outq 0>: recv 60 <d=0 p=1 f=DAT> Is this for sure an error and loss of data? or there is a normal situation that such a thing can happen? For example when the whole block can't be sent over one connection? (otherwise how do the tl tests all pass?). Further more, I merged the payload scraper and stegotorus. I this way, http_apache checks for the payload database and if it's not there it calls the scraper (it needs apache to be installed on the same machine). These all are commited on the github. I started writing a unit test that fetch a webpage directly (using curl) and through stegotorus and check if they are the same. I thought curl is best approximation of a browser that is available to us. But as I don't think I can finish that till tomorrow, I'm going to spend the remaining time on documenting the 'uri transport protocol' and deal with small issues. After we are done with the evaluation, I'll go back to unit testing. Thanks for your help. Cheers, vmon

2 2

Re: [tor-dev] TBB Gentoo ebuild
by julian 27 Aug '12

27 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 12 Aug 22:56 Mansour Moufid: > Even with webrsync you still have to trust the mirror(s), and then > the Gentoo release infrastructure... Forgive me my bluntness, but how is that different from trusting you? The methods are reliable, being Manifests and webrsync, the unknown variable is the trust you give the ones providing you with ebuilds. But those are identified by gpg on both levels. And the TBB is even worse, cause I also have to trust what's in the binaries. There is no way to tell what was actually compiled there. It could be something different than the sources on the git server. 13 Aug 00:28 Matthew Finkel: > 4) Given 3), is there a reason Tor is not at least an optional > RDEPEND for torbrowser via a USE flag (or another way)? There are no optional runtime-only dependencies in gentoo, this could change with GLEP 62. http://www.gentoo.org/proj/en/glep/glep-0062.html I could however tell the user after compilation that he might want to use tor with this...erm... but I thought that's obvious. The fact that it's not forced for RDEPEND is simply, because there are setups where this is not wanted/required. 13 Aug 00:28 Matthew Finkel: > 5) If you did/do intend to create an ebuild for the TBB and not > just the browser, it should provide the exact same experience as if > the user downloaded it from torproject.org. I think this should > include Vidalia launching Torbrowser once the network is > configured. Definitely not. The intention is not to provide an all-in-one experience. I already had those arguments with the guys from #tor All I am interested in is the question about the firefox build-time configuration and if different build-time configurations could lead to vulnerability in the tor network. If there is the slightest doubt about that, I will remove this ebuild at once or fix it. - - hasufell -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJQOpaJAAoJEFpvPKfnPDWzpI4H/igZDuVGyjdKEl9SvvV9gnY0 72esQTiHfx00gO42lOguutwBX54DV/S7HggEZy1P9UIi5gfJckrFKsM3Y9oD9tUX X9EZA6WEU3F90MD0gFFxH2jcoEbm85UfjJkEwI2Hy1+lEOPAZqzBV1F0sBE/Xd/U WwIgAHy8jKsTI1RTIW8r4VOoexifCllWvjbKiDNxeeixTQhwhvrCWnbqTI0WKR95 Er6LNwwYNh+Ugu7s6OwR7o3cUAuOXt3LUjf45bEGAgPF+lrqsXrfB9N5ANu+3177 94sxHgzYkRSsORjjl678/tZFfyp1jagX1FcT6O1dd/J4sHqfRdyZfy29d0DH/e0= =gCI5 -----END PGP SIGNATURE-----

3 3

First five Tor tech reports
by Karsten Loesing 27 Aug '12

27 Aug '12

Hi Roger, hi Nick, here are the first five metrics tech reports that I'd like to turn into Tor tech reports (see #5405 for the idea behind this). If you agree that this is a good idea, I'll push the sources to tech-reports.git and put the PDFs on the Tor website. I need your confirmation for each report as part of the process, though. - https://people.torproject.org/~karsten/volatile/bridge-stability-2011-10-31… - https://people.torproject.org/~karsten/volatile/blocking-2011-09-15.pdf - https://people.torproject.org/~karsten/volatile/detector-2011-09-09.pdf - https://people.torproject.org/~karsten/volatile/relay-stability-2011-06-30.… - https://people.torproject.org/~karsten/volatile/data-2011-03-14.pdf Thanks, Karsten

6 15

https://gitweb.torproject.org/check.git
by bgt56zhn＠Safe-mail.net 26 Aug '12

26 Aug '12

Where is the code powering check.torproject.org? There is https://gitweb.torproject.org/check.git, but the repo has no commits. Thanks

3 2

an alternate MyFamily definition
by tagnaq 24 Aug '12

24 Aug '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi, when requesting a new group by feature for compass [1] (#6662 [2]) I discussed with Karsten about how to handle asynchronous/overlapping families: karsten: > Here's an example. Assume we have three relays: A, B, and C. These > relays state the following family relationships: > > A: A, B B: A, B, C C: B, C > > We require mutual agreement about being in the same family, so we > could either come up with family A, B or with family B, C. Which > one is correct? I proposed to go with family = A, B, C because there is a mutual agreement between A<->B and B<->C. A and C agreed to be in a family with B, and B agreed to be in a family with A and C. Such configurations can be found in the wild mostly due to incomplete MyFamily configurations on relays in big families. As every big relay operator knows configuring families is a non-trivial effort with a growing number of relays. Now I thought about it and wanted to suggest this MyFamily interpretation as an alternate approach to the fully mutual setup where *every* relay must be reconfigured as opposed to just two of them. Why? This would reduce the configuration effort required when adding a new relay to *two* relays regardless of how many relays are in your family. Now, the MyFamily configuration overhead for big families is a well known problem so I suppose someone else did already propose this approach? What do you think about it? [1] https://compass.torproject.org [2] https://trac.torproject.org/projects/tor/ticket/6662 a additional example to make this clearer: A: A, B, C B: A, B, C C: A, B, C D: A, B, C, D family = A, B, C A family member must have a *mutual* agreement with at least *one* node. -----BEGIN PGP SIGNATURE----- iF4EAREKAAYFAlA2YkoACgkQyM26BSNOM7Yp2wD/VTBw8BmUJlRZtIfXahIGX+t0 zwzP6MfRDwgPCsQMeEUA/3dUyyoq91Fx4lmihWHis2DZNAoM/CHh2MnwgMNL/W1W =FWRU -----END PGP SIGNATURE-----

3 4

[GSoC] [Stegotorus] Pencil down
by vmon 23 Aug '12

23 Aug '12

Hey Zack, I just did my last pushes before putting my pencil down for the final evaluations. They take care of the followings: - The remaining of all your comments on the github. Except for "always use xalloc instead of new". I have used new extensively for instantiating objects. What's exactly about xalloc that's better than new, if you have overloaded both of them? - Documenting the http_apache steg protocol. The tl_oneway_c2s fails the http-proxy test. It still have problem with one-sided EOF. It used to pass when I allow the one way socket shutdown in the http proxy. So, I think stegotorus still have problem with EOF management. You might want to look at it when you have time. Happy moving! vmon

2 1

Tor and NAT devices: increasing bridge & relay reachability or, enabling the use of NAT-PMP and UPnP by default.
by Jacob Appelbaum 22 Aug '12

22 Aug '12

Hi, My latest tech report is now up. I think it would be a nice idea if we could kick off a discussion about Tor, NAT devices and reachability. Tor and NAT devices: increasing bridge & relay reachability or, enabling the use of NAT-PMP and UPnP by default: https://research.torproject.org/techreports/tor-nat-plan-2012-08-22.pdf Feedback welcome and encouraged! All the best, Jake

1 0

[ooniprobe-dev] Summary of OONI hackfest
by Arturo Filastò 22 Aug '12

22 Aug '12

We had a mini hackfest at noisebridge on OONI and this thread is to summarize what we discussed. mct: feel free to add things from your notes that are not detailed here. One of the problems that we mostly focused our attention on was how to detect censorship on HTTP when the user is presented with a block page. The reason for focusing on this is that censorship over HTTP is the most prevalent form. # Detecting censorship in web sites Detecting that the presented web page is not the expected site, but is a censorship page turns out to be a non trivial task, especially when you are dealing with web pages that have dynamic content. This problem is detailed in this trac ticket: https://trac.torproject.org/projects/tor/ticket/6180. We ended up dividing the possible approaches into two macro categories: Statistical and Heuristic [1] One of the properties we would like our classifier to have is that that a user should be able to detect that the presented page is the block page by just having a copy of OONI and some data that can be given to them over a non censored channel (sneakernet for example). ## DOMClass, a eigenvalue based statistical classifier What we ended up implementing is a classifier that considers the DOM structure of the web page. We can easily build such a database of the DOM structure features of the websites we are interested in analyzing and ship these to users. This is how the algorithm works: This classifier uses the DOM structure of a website to determine how similar the two sites are. The procedure we use is the following: * First we parse all the DOM tree of the web page and we build a list of TAG parent child relationships (ex. <html><a></a><c></c></html> => (html, a), (a, b), (html, c)). * We then use this information to build a matrix (M) where m[i][j] = P(of transitioning from tag[i] to tag[j]). If tag[i] does not exists P() = 0. Note: M is a square matrix that is number_of_tags wide. * We then calculate the eigenvectors (v_i) and eigenvalues (e) of M. * The corelation between page A and B is given via this formula: correlation = dot_product(e_A, e_B), where e_A and e_B are resepectively the eigenvalues for the probability matrix A and the probability matrix B. You will note that the Matrix we are computing eigenvalues for somewhat resembles a Markov model for transitions between DOM element X to Y. This algorithm appears to work pretty well even on highly dynamic web sites (such as the homepage of news.google.com) Problems with this algorithm: * It does not take into account the global position of DOM elements or how deeply nested they are. (<a><a></a></a> (a,b),(b,a),(a,b) is equivalent to <a><a></a></a><a></a> (a,b), (b,a), (a,b)) Looking into other possible solutions to this problem I took a look at algorithms that are used to compute graph similarity. This problem could be solved by using an algorithm that calculates the maximum isomorphic subgraph, but this problem is NP-hard. [2] I am unsure if the computation effort to use algorithms along these lines is worth while. I can't seem to find the notes on the rest of the discussion, perhaps mct will integrate with this discussion. - Art. [1] https://trac.torproject.org/projects/tor/ticket/6180#comment:3 [2] <http://en.wikipedia.org/wiki/Subgraph_isomorphism_problem>http://en.wikipedia.org/wiki/Maximum_common_subgraph_isomorphism_problem

1 0

[GSoC] APAF Report
by Michele Orrù 21 Aug '12

21 Aug '12

Hello, As Daniel suggested, I'm writing this email to keep you updated on my Google Summer of Code Project - APAF. Following the hackathon of the 18-21 May, we reached a working build environment, and a primitive administration page. Below follows a brief update about what is the current status of the software: Development: I've defined what a service really is in terms of implementation, and approached the administration service (the "panel") in such a way that any future application may hide or completely override it. This shall give not only a comfortable user experience but also elasticity to the software. Testing: unittests cover most of the software, but even though APAF is still in an embrional state, I would be glad anyway to receive some feedbacks from you, about which OS the apaf was tested on and any bug you were able to find. Documentation: currently is disorganized, and splitted between sphynx and github wiki. But, the data is there, and I promise that on the next days I will merge/rewrite the two :) Anyway, the code is highly documented, in my opinion the generated sphynx documentation is acceptable. Deployment: I kept working on the build system, which at the current revision works on windows, osx and as vanilla python .egg., but there are still some issues - for example, the automation of .deb build and blobbing external tools on windows. In case you need a quick link to the project, https://github.com/mmaker/apaf -- ù

4 15

IRC meeting to plan sponsor L milestones on Wed July 18, 15:00 UTC in #tor-dev
by Karsten Loesing 15 Aug '12

15 Aug '12

Hi everyone, we have an upcoming sponsor contract starting on October 1, 2012 and running until August 31, 2013. To be precise, this contract is not signed yet, but it's very likely to happen. The general deliverables are already defined, but we can suggest which parts we plan to have done by which milestone. The deliverables can be found here: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorL I suggest we have an IRC meeting with all developers who'll be involved in this contract. Deliverables are, of course, not yet assigned to developers. Here are the people who probably should be at the meeting (with most relevant deliverable numbers in parentheses): - Aaron (4) - Erinn (9, 10) - George (1, 2, 3) - Jake (10) - Karsten (2) - Mike (8) - Nick (3) - Runa (5, 6, 7) - Sebastian (9) - Tomas (9) The meeting will happen July 18, 15:00--17:00 UTC in #tor-dev. The main goal of the meeting is to decide on good milestones for December 31, March 31, June 30, and August 31 that will go into the contract. If somebody cannot make the meeting, please talk to me about their possible deliverables before or shortly after the meeting. (If too many people cannot make the meeting, we may reschedule it, but for the moment, let's aim for the date written above.) Thanks, Karsten

5 12

My RSA-PM client-server
by Daniel Dennis 14 Aug '12

14 Aug '12

Last month I posted a message titled "Encrypted PM site/hidden service" inquiring about websites or services that allow users to write messages. I got a few interesting replies but none did exactly what I wanted. So I wrote up this code and put it on github. The major things to note are - Supports Windows and Linux (likely mac as well) - Written in C# .NET - Has a mono and non mono (plain windows) build - Is written in mind to NEVER TRUST THE SERVER - Client has the contents (re-)encrypted in a local database I spent some time ensuring it works perfectly. I was able to reach the server when it was behind a hidden service, I ran client and server on linux and windows. Everything worked as expected. https://github.com/sdjfjsdfiuhszduh/RSA-PM I don't want to host anything myself. It would be nice if someone could so whistle blowers could talk to others securely. If anyone goes through the code let me know what you think. Although I wrote it quickly so it may be confusing to others. -- http://www.fastmail.fm - IMAP accessible web-mail

1 0

Pyonionoo
by Norman Danner 14 Aug '12

14 Aug '12

Hi Karsten, We have a preliminary version of the Pyonionoo front-end at git://github.com/meganchang/pyonionoo.git Make sure to look at the database branch. We'd be happy to hear feedback. Unfortunately, this isn't as far as we wanted to be. A run-down of the main open issues: * We ran into issues with getting sqlite in-memory databases to play nicely with multiple threads (stop-gap solution: use an on-disk database). * Right now it just has the summary handler, though adding the other handlers probably isn't a problem (probably a bit of minor refactoring). * The search GET parameter isn't implemented yet, in part because we realized that implementing it as specified in the protocol isn't so straightforward, at least in SQLite (which does not, in an obvious way, support searching for initial substrings). - Norman -- Norman Danner - ndanner(a)wesleyan.edu - http://ndanner.web.wesleyan.edu Department of Mathematics and Computer Science - Wesleyan University

3 6

TBB Gentoo ebuild
by Alessandro Di Federico 14 Aug '12

14 Aug '12

Hi, I'm trying to put up an ebuild for the Tor Browser Bundle for Gentoo. As you may know an ebuild is a script which automates the build of a certain application. We already have something in Portage [2] (the official ebuild repository) but it's in an experimental state and we want to make sure that it's something useful and not harmful. So I'd like to know your opinion about the idea as whole (is it a good idea at all to build by yourself the TBB instead of using the official one?) and what could be the main problems arising in such an operation. So: 1. Can you name a list of tools to fingerprint a browser so we can compare our ebuild with the official TBB? 2. Which version should we use? We were planning to offer both the current official release (even if TBB for Linux is currently in beta) and something more recent, even if AFAIK this would be for testing purpose only and could weaken anonymity and untrackability. 3. We plan to use the system version of the Tor client, in my understanding it should not be a problem to use a Tor client with a version different from the one officially released, but I could be wrong. We also plan to exclude vidalia (and the "0015-Make-Tor-Browser-exit-when-not-launched-from-Vidalia.patch" patch). 4. We have a different ebuild for the Firefox profile directory (so if it's not installed the HTTPS Everywhere plugin won't be installed), is this a good idea or would it be better to integrate them? 5. Gentoo build system offers USE flags, which are options that allow to customize the way the package is built. These are the USE flag available for the standard Firefox ebuild in Gentoo, which is the base for our build of the TBB: 1. alsa: Adds support for media-libs/alsa-lib (Advanced Linux Sound Architecture) 2. bindist: Disable official Firefox branding (icons, name) which are not binary-redistributable according to upstream. 3. custom-cflags: Build with user-specified CFLAGS (unsupported) 4. custom-optimization: Fine-tune custom compiler optimizations, setting this is not recommended. 5. dbus: Enable dbus support for anything that needs it (gpsd, gnomemeeting, etc) 6. debug: Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see http://www.gentoo.org/proj/en/qa/backtraces.xml 7. ipc: Use inter-process communication between tabs and plugins. Allows for greater stability in case of plugin crashes 8. libnotify: Enable desktop notification support 9. minimal: Prevent sdk and headers from being installed 10. pgo: Add support for profile-guided optimization using gcc-4.5, for faster binaries. This option will double the compile time. 11. startup-notification: Enable application startup event feedback mechanism 12. system-sqlite: Use the system-wide dev-db/sqlite installation with secure-delete enabled 13. webm: Use system media-libs/libvpx for HTML5 WebM video support. 14. wifi: Enable wireless network functions Looking at the TBB build script this the combination of USE flags to make as similar as possible to the official release (minus means the USE flag is disabled): -pgo -debug -bindist -custom-optimization -crashreporter webm ipc system-sqlite -wifi. I'm planning to remove the possibility to configure these use flags. Do you agree? For further details you can take a look at the ebuild [1], which should be understandable. Take a look also at the current ebuild for TBB [2]. Is there something else we should pay attention to in the build process or in general? Thanks in advance, Alessandro Di Federico [1] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/firefox/… http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/mozconfig-3.… [2] http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-client/torbrows…

3 5

[GSoC] [Stegotorus] update
by vmonmoonshine＠gmail.com 13 Aug '12

13 Aug '12

Hello Tor-devers, In last two weeks I was busy implementing the protocol by which the st server sends a url dictionary to the client, so they the client can communicate with server using this url code. It was bit tricky because chop needed to be involved to distinguished between the data being serve to the user and the data for the steg module. This is working now. I also made the curl st client to st server communication non-blocking and now curl sharing the socket with libevent (for the reply). The curl communication with apache server (for providing covers) is still blocking. This is not critical as long as the cover webserver and st server are on the same machine, but is a good feature to think about. You can get everything here: https://github.com/zackw/stegotorus/tree/f--payload-servers But you need to have apache installed on the server and run payload_scraper first: https://github.com/vmon/payload_scraper then copy the generated payload list into apcahe_payload/server_list.txt The name of steg protocol is http_apache (instead of http) The next 10 days will be writing unit tests, testing, and writing documentation for http_steg protocol. Cheers, vmon

1 0

Fwd: [tor-relays] tcmalloc in FreeBSD
by Jordi Espasa Clofent 11 Aug '12

11 Aug '12

Hi, I posted this message in tor-relays, but it seems to me (and another people) that dev mail-list is better channel to use. Thanks! -------- Original Message -------- Hi all, From time to time my tor node (minibofh) stopped to work properly; since it's a tiny FreeBSD VPS, the root origin was some CPU over-consumption. I'm taking some actions to fix it (more swap, freeing CPU from another services... etc). The FreeBSD tor port offers to you the tcmalloc compilation option, so I had some fun reading this interesting paper: http://goog-perftools.sourceforge.net/doc/tcmalloc.html I recompiled the tor port but just using the tcmalloc option. Actually, now I got the google-perftool package and, obviously, the tcmalloc library: mb# pkg_info | grep google google-perftools-1.8.3 Fast, multi-threaded malloc() and nifty performance analysi mb# pkg_info -L google-perftools-1.8.3 | grep malloc.so /usr/local/lib/libtcmalloc.so /usr/local/lib/libtcmalloc.so.2 But, when I'm checking which libraries the tor binary is using, I get: mb# ldd /usr/local/bin/tor /usr/local/bin/tor: libz.so.5 => /lib/libz.so.5 (0x281aa000) libm.so.5 => /lib/libm.so.5 (0x281bc000) libevent-2.0.so.6 => /usr/local/lib/event2/libevent-2.0.so.6 (0x2844e000) libssl.so.7 => /usr/local/lib/libssl.so.7 (0x28489000) libcrypto.so.7 => /usr/local/lib/libcrypto.so.7 (0x284d7000) libthr.so.3 => /lib/libthr.so.3 (0x281df000) libc.so.7 => /lib/libc.so.7 (0x28090000) So... I understand that the tor binary is actually NOT using the new tcmalloc library. Am I wrong? PS. I adding a CC to tor FreeBSD port mantainer.

4 19

Another key exchange algorithm for extending circuits: alternative to ntor?
by Nick Mathewson 11 Aug '12

11 Aug '12

Hi, all! Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in submission called, "An Efficient Key-Exchange for Onion Routing". It's meant to be more CPU-efficient than the proposed "ntor" handshake. With permission from Esfandiar, I'm sending a link to the paper here for discussion. http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html What do people think? -- Nick

3 7

[Stegotorus] Strange comparison in chop_circuit_t::send_targeted(conn, blocksize)
by vmon 10 Aug '12

10 Aug '12

Hey Zack, Please take a look at this comparison in chop_circuit_t::send_targeted(conn, blocksize): if (avail > blocksize - lo) avail = blocksize - lo; else if (avail > SECTION_LEN) avail = SECTION_LEN; else if (upstream_eof && !sent_fin) // this block will carry the last byte of real data to be sent in // this direction; mark it as such op = op_FIN; Assume SECTION_LEN = 65536 suppose avail = 67000 blocksize - lo = 66500 => avail = 66500 avail = 67000 blocksize - lo = 67500 => avail = 65536 it's like that if avail is very big then the it is OK if it's bigger than SECTION_LEN but if it's moderately big then it shouldn't be bigger than SECTION_LEN, which seems very arbitrary. On the other hand if blocksize - lo < SECTION_LEN again it doesn't make sense, because then it never reaches to (avail > SECTION_LEN). So it's like if SECTION_LEN < blocksize - lo the behavior is random and if it's SECTION_LEN > blocksize - lo is useless. Moreover, when blocksize - lo > avail > SECTION_LEN I'm getting assertion error in the other overload of send_targeted. Everything makes sense and the assertion failure goes away if I replace the code with this: if ((avail > blocksize - lo) || (avail > SECTION_LEN)) { avail = min(blocksize - lo, SECTION_LEN); } else if (upstream_eof && !sent_fin) // this block will carry the last byte of real data to be sent in // this direction; mark it as such op = op_FIN; Please tell me what you think and if the second chunk is the correct replacement? Bests, vmon

2 1

Re: [tor-dev] Another key exchange algorithm for extending circuits: alternative to ntor?
by aniket kate 09 Aug '12

09 Aug '12

> Date: Thu, 9 Aug 2012 00:22:59 +0000 > From: Robert Ransom <rransom.8774(a)gmail.com> > > On 8/8/12, Nick Mathewson <nickm(a)freehaven.net> wrote: > >> Michael Backes, Aniket Kate, and Esfandiar Mohammadi have a paper in >> submission called, "An Efficient Key-Exchange for Onion Routing". >> It's meant to be more CPU-efficient than the proposed "ntor" >> handshake. With permission from Esfandiar, I'm sending a link to the >> paper here for discussion. >> >> http://www.infsec.cs.uni-saarland.de/~mohammadi/owake.html >> >> What do people think? > > > * If you finish my implementation of the Ed25519 group operations > (which you would need in order to implement this protocol), you can > use them to implement a signature-based protocol (specified as > A-DHKE-1 in http://eprint.iacr.org/1999/012) which requires only one > precomputed and one on-line exponentiation per protocol run on the > server when implemented with a slightly modified version of Ed25519. > (The client's performance is much less important than the server's.) I went through A-DHKE-1 description (Page 36 of Eprint 1999/012). I find that A-DHKE-1 also requires one online signature generation on the server side along with one online exponentiation. Therefore, A-DHKE-1 is computationally more expensive than the discussed protocol and probably even the ntor protocol based on the employed signature scheme. -Aniket

2 1

How about virtual machines?
by Admin 09 Aug '12

09 Aug '12

Hello Developers, My testing shows that you can setup encrypted virtual machines in a country with easy access to broadband, and have someone from a country where good computer hardware is hard to find, the Internet got cut off to a point where only dial up is available, and manage to give these people access to broadband and high range hardware. In order to do this, you need to setup a remote desktop virtualization, where the user is able to use all of the resources of a virtual machine, while only using it's current device for rendering the screen of the vm and as keyboard, mouse or touch input. This virtual machine could reset it's state once the user logs off, leaving no trace of what he did while he was on it. Considering the only connection the user is actually making is to the vm location, there is way an oppressive government can figure out which sites are currently being visited or what the user is doing, unless it is already inside taking screenshots and keylogging. There is also the possibility of making cheap dial up enabled USB dongles, which are specialized in screen rendering by PCoIP and can be connected to any device, such as a smart tvs and tablets. Testing shows you can make Android virtual machines for those connecting through a touch enabled device, and keep the device's touch functions. Let me know what you think. Cheers

1 0