- tor-dev - lists.torproject.org

test_memcpy() on Windows
by Gisle Vanem 14 Mar '14

14 Mar '14

The 'test_memcpy()' in tinytest_demo.c assumes there is a NUL in one of the buffers. (the comment says so). That's not the case here on Windows. At least not in MSVC debug-mode where malloc'ed buffers are filled with '0xCD'. A snippet from my output: ../ext/tinytest_demo.c:159: assert(db->buffer1 < db->buffer2): 537472696E67203000CDCDCDCDCDCDCDCDCDCDCDCDCD ... vs 537472696E67203000CDCDCDCDCDCDCDCDCDCDCDCD ... [memcpy FAILED] I assume this test works on Linux where AFAICS malloc() returns a buffer with zeros. If so, shouldn't calloc() be used in 'setup_data_buffer()' instead? --gv

2 2

[Patch] tinytest_demo.c
by Gisle Vanem 14 Mar '14

14 Mar '14

Since tinytest_demo.c now calls Sleep(), we must include <windows.h>. Patch: --- Git-latest/src/ext/tinytest_demo.c 2014-03-13 20:44:56 +0000 +++ src/ext/tinytest_demo.c 2014-03-14 11:21:56 +0000 @@ -36,7 +36,10 @@ #include <string.h> #include <errno.h> #include <time.h> -#ifndef _WIN32 + +#ifdef _WIN32 +#include <windows.h> +#else #include <unistd.h> #endif -------------- Ref. Nicks commit here: https://gitweb.torproject.org/tor.git/commitdiff/1365ff5b9a04a7da2acc2e52df… --gv

2 1

No IRC meeting to discuss Tor Instant Messaging Bundle today
by Karsten Loesing 14 Mar '14

14 Mar '14

Hi devs, we had an IRC meeting last week, on March 7, to discuss next steps for the Tor Instant Messaging Bundle (TIMB). At the end of that meeting we decided to have another meeting 1 week later, so today. However, there will be no such meeting today! The main reason for today's meeting was to make a decision on an instant messaging client to use in the new bundle. But we already made this decision in internal discussions with the main developers Arlo and Sukhbir. The final decision is that we're going to use Instantbird. The wiki page states some reasons for this decision: https://trac.torproject.org/projects/tor/wiki/org/sponsors/SponsorO/TIMB If you had planned to attend today's meeting to find out how to best help out with the project, please be patient. The project is still in an early state, and we don't have a good list of things that we need help with. Maybe take a look at the Trac tickets in the TIMB component and at the wiki page linked above. There will be IRC meetings in the future to discuss progress on this project, I just can't say when that will be. Thanks for your patience, and thanks for wanting to help out! All the best, Karsten

1 0

A few questions about defenses against particular attacks
by Yuhao Dong 14 Mar '14

14 Mar '14

Hi, I am currently working on a personal project implementing an onion-router, vaguely similar to Tor (let's just call it Oor, other onion router, for the moment), and I have a few questions about attacks, which I think are not really protected by Tor, and whether my solution could possibly work. Of course, if Tor defends against such attacks, then please enlighten me. - Traffic volume correlation. Tor's FAQ says that it doesn't plan on defending against an adversary monitoring traffic volumes flowing through the Tor network. Oor tries to protect against this attack by: - Obfuscating every single link with a protocol derived by Tor's obfs3 protocol - No public list of all node addresses; this makes determining whether certain traffic is Oor traffic much harder. More at the next bulletpoint - Splitting each circuit (termed "onion stew") into many subcircuits, all terminating at the same exit node. à la multipath TCP. Cells going through the subcircuits have a randomly-determined *uneven *distribution of choice of subcircuit, barring attackers from deducing total traffic from observing one subcircuit. - Blanket blacklist attacks by censors. Censors can poll the directory and block all ordinary Tor nodes. (obfsproxy) bridges are a workaround. - Oor's directory maintains a *graph* of all nodes. Each node knows the public keys of all the other nodes, but each node only knows the addresses of *adjacent* nodes. - Note that this allows (sub)circuit-building along any path in the graph. The "extend circuit" command takes the next node's public key as the parameter, rather than the address. - This reduces the bootstrapping problem to distributing (an alias of) the directory server address. Unlike with Tor bridges, this does not create a bandwidth bottleneck, and no nodes need to be reserved for a special pool of bridges, unable to be used by usual users. Bridges often go offline, but this would work until the alias is blocked. However, as with Tor bridges, things like e-mail can be used to distribute many dynamically-generated aliases of the directory server. - Protocol recognition. In "free" countries like the US of A, Tor users see no pressure to use obfuscated bridges. Tor traffic is rather easily distinguished, and could be used to form suspicion on people. Even with obfsproxy, Tor's constant 512-byte cell length may be an issue. The "Stegotorus" paper presents a filter that finds cell lengths typical of Tor. - Every link is obfuscated in oor with obfs3. - obfs3 happens to create various cell lengths. This would be a problem for Tor-like circuits because it doesn't hide data sizes at all, but I think that breaking circuits into subcircuits solves this problem. There is a not-really-working but readable PoC implementation of everything except the "onion stewing" part, i.e. circuits can only work with one subcircuit, athttps://github.com/quantum1423/kirisurf-dev/ Current work is underway to rewrite a more robust version with various repos at https://github.com/KirisurfProject/ (yes, it is currently called Kirisurf, oor is just for short previously, and I want to change the kirisurf name anyways. You may find a "kirisurf" on sourceforge. That is a simple one-hop encrypted proxy I made a long time ago just for breaking censorship without privacy protection; Kirisurf gradually grew onion-routing things until I decided to redesign it; namechange probably needed to prevent misleading version numbers) I would be interested to know what research has been done on these areas in Tor (to avoid reinventing the wheel), and whether any of my ideas are novel. Thanks!

2 1

Fwd: [Twisted-Python] Tor Project has GSoC projects which need Twisted developers!
by isis 14 Mar '14

14 Mar '14

I sent this to the Twisted mailing list at twisted-python(a)twistedmatrix.com -- ♥Ⓐ isis agora lovecruft _________________________________________________________ GPG: 4096R/A3ADB67A2CDB8B35 Current Keys: https://blog.patternsinthevoid.net/isis.txt

1 0

Pluggable transports meeting tomorrow (Friday 14th of March 2014)
by George Kadianakis 13 Mar '14

13 Mar '14

Greetings humans, this is an email to remind you that the regular biweekly pluggable transports meeting is going to happen tomorrow. Place is the #tor-dev IRC channel in OFTC. Time is 17:00 UTC. Cheers!

1 0

GSoC - Search Engine for Hidden services
by Nurmi, Juha 13 Mar '14

13 Mar '14

Hi All, Ahmia.fi interested in participating in GSoC. Ahmia.fi's back-end is designed by Kordex (Mikko Kortelainen) and I (Juha Nurmi) have built the front-end. In practise, I will apply as a student. Also, kordex might apply. Ahmia.fi is a HS search engine that needs improvements. At the moment, we are using YaCy in the back-end and have developed Django based front-end (Python). Kordex is a Customer Service Architect, CEO of the Fail-Safe IT solutions and software designer. I am a research, postgraduate student and university lecturer. I have a long work experience with web services. At the moment, ahmia.fi has integration to Tor2web and Globaleaks. We have hidden service online cheker, RESTful API for the resources, tested idea how hidden services could publish their information ( https://ahmia.fi/documentation/descriptionProposal/) and a lot of good ideas. Unfortunately, we do not have any funding. We would like to release the source code of ahmia.fi and develop our search engine in GSoC. Greetings Juha Nurmi

3 2

GoSC - Website Fingerprinting project
by Marc Juarez 12 Mar '14

12 Mar '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I'm a PhD student at COSIC (COmputer Security and Industrial Cryptography) in KU Leuven, Belgium. My research topic is related to network traffic analysis and I'm now focused in the more specific problem of website fingerprinting (http://homes.esat.kuleuven.be/~mjuarezm/) I think website fingerprinting is one of the most threatening attacks to Tor because it can be deployed with moderate resources and the information that can be extracted as a result is highly sensitive (e.g., browsing history). It basically defeats one of the main privacy guarantees offered by Tor which is unlinkability between sender and recipient or, in this particular case, between the user and the web server. However, I couldn't find any open project that tackles this problem in https://www.torproject.org/getinvolved/volunteer.html.en#Projects. That is why I'd like to propose a GoSC project for the implementation of tools (packages, classes, etc.) that contribute in the development of a countermeasure against this attack. Regarding countermeasures, since Tor is oriented to low-latency applications like web browsing, delaying strategies are unacceptable and, therefore, they must necessarily be based on link-padding. Link-padding normally incurs in high bandwidth overheads, however the increasing broadband bandwidth capacity available makes it a relevant feasible defence. Some capabilities for link-padding have been already specified for Tor by Steven Murdoch (https://gitweb.torproject.org/torspec.git?a=blob_plain;hb=HEAD;f=tor-spec.t…, Section 7.2). This functionality is very useful for such a countermeasure but more sophisticated protocols are required for countermeasures that try to adjust the bandwidth overhead. There are several proposed countermeasures based on link-padding that strive for such a trade-off that might be interesting to implement: - Congestion-Sensitive BuFLO (http://arxiv.org/abs/1401.6022) - Adaptive Padding (http://freehaven.net/anonbib/cache/ShWa-Timing06.pdf) Both countermeasures have some building blocks in common (e.g., a control logic to adapt padding under some specific conditions and reduce the overhead). The core of the project would be to implement them in the most general way as possible so they can be useful for other link-padding applications. For example, to implement the basis for a statistical model in the onion proxy and the entry guard that generates the appropriate cover traffic in both directions, where ?appropriate? would be abstracted as it would be defined by each specific countermeasure. I would like to have some feedback from the Tor developers about this project (advices, comments..). I plan to specify it in more detail in the application and to start coding some module that could be shown. But I would like to know if the underlying idea is something that could be of interest for the community. Also, as a PhD student I'm also committed with my research group during the summer so I would like to know if I could work as a part-time student. Best, - -- marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHe+dAAoJEGfJ5xfgazlxYewH/jHv3843o0lQHpHksur86dih u1MtFOpo3RvzdOLNAjdMpnV14Giy8cg0mIcYdCgwCy8jyUgBS5ipX49582Tmf6FT sPYYWOSIBEJVG3DYsD2PwU+XJAiyR9GqdiMiP9MeCJHWP33TBL5hY1TExBejiH+J XsAWo8D2MkzycKITF1leuX4n2eCqncDIy+owU4faYIRj5wPtqwztWDX4ErfdFhws sb/wLF8Wb0tKio/ybkuy5UZeJi0UBF9hAh5UJfZRSllfMFN9g29pJPmTsenMTBS0 XxEEG8gNjHgxpV4rkcTMQBeNp+CAEBsZ7qjxo6IXvLIe0P6zutyQysu9hJCvvY4= =AZG8 -----END PGP SIGNATURE-----

5 4

Weekly Tor dev meeting today, in 90 minutes. (19:00 UTC!)
by Nick Mathewson 12 Mar '14

12 Mar '14

Oh dear. Daylight Savings Time has struck again. The dev meeting this week needs to be at 19:00 UTC, so that I can be done by 4 pm. If you can make it then, great! Else, next week at 19:00 UTC. yrs, -- Nick

1 0

Minutes from Weather rewrite meeting on March 5
by Karsten Loesing 12 Mar '14

12 Mar '14

- only participants today: baumanno and karsten - karsten starts reporting what he did since last meeting - karsten reviewed two tickets - karsten wrote down GSoC idea (u. Rewrite Tor Weather on https://www.torproject.org/getinvolved/volunteer.html.en#Projects) - karsten defined criteria for sending out welcome mails using Onionoo's details documents (#11084) - baumanno starts reporting what he did since last meeting - baumanno closed issue reported by karsten on GitHub repo - baumanno and karsten agreed that there should be unit tests in weather; baumanno is going to create a ticket for this after the meeting; there should be some unit testing framework that plays well with Django - baumanno used most of the existing weather code for scraping emails from relay descriptors - baumanno went on to begin implementation of the welcome script, which leads to #11084 - baumanno notes that we're still missing the script nufuk is working on; baumanno is going to ping him via email and suggest that either feverDream or baumanno takes over - baumanno and karsten wonder how far feverDream is with the vagrant box; this will be very useful to have - baumanno says that utility scripts are ready, so that branching off stable weather would make sense - karsten asked tor's git admins for a user/karsten/weather.git repo that we can use as new stable for now; this is going to be much easier than for feverDream or baumanno to ask for a repo on tor's git - baumanno is going to keep tickets open until we merged them into user/karsten/weather.git - baumanno will create a new branch from atagar's weather repo, add commits, push to a new branch on github, and comment on a trac ticket to pull/review/merge; he's going to cc karsten on the ticket - next meeting is next wednesday at 18:00 utc

1 1