- tor-dev - lists.torproject.org

[RESEARCH] Student of University of Verona, Thesis about TOR
by Diego Sempreboni 02 Feb '15

02 Feb '15

Hi, I am a student of Engineering of the University of Verona. For my master's thesis, I decided to analyze TOR network, analyzing various attack scenarios. By consulting several documents have not been able to obtain a pattern of messages exchanged during the handshake protocol nor other details about the packets exchanged later. It would be possible to have some information about this? I write hoping someone can help me. Thank you.

3 2

Estimating censorship lag by obfs4 blocking
by David Fifield 02 Feb '15

02 Feb '15

According to a couple of blog comments on February 1, 2015, the default obfs4 bridges are blocked by GFW. https://blog.torproject.org/blog/tor-browser-45a3-released#comment-86416 https://blog.torproject.org/blog/tor-browser-45a3-released#comment-86907 The obfs4 bridges were introduced on November 17, 2014. https://blog.torproject.org/blog/tor-browser-45-alpha-1-released I have a message from Yawning Angel verifying that the obfs4 bridges were reachable on December 2, 2014. With this information, we can put rough bounds on how long it took the GFW to react to a new circumvention system: between 2 and 10 weeks. Does anyone know information that could tighten up the bounds, a date between December 2 and February 1 when obfs4 bridges were known to be either accessible or inaccessible? David Fifield

1 0

Damian's Status Report - January 2015
by Damian Johnson 01 Feb '15

01 Feb '15

Greetings wonderful world. January has been delightfully focused on a couple substantial feature branches that are now merged! -------------------------------------------------------------------------------- Descriptor Lazy Loading -------------------------------------------------------------------------------- When reading descriptors without validation (which is now the default) Stem is 25-70% faster! https://lists.torproject.org/pipermail/tor-dev/2015-January/008211.html This is because we now parse descriptors fields on-demand. Just need a server descriptor's exit policy? That's all we'll bother reading. This is why the heavier the descriptor type the larger the benefit. -------------------------------------------------------------------------------- Unified Python 2/3 Codebase -------------------------------------------------------------------------------- Thanks to Foxboron Stem now has a unified python 2/3 codebase! https://trac.torproject.org/projects/tor/ticket/14075 This means that Stem now runs directly with any version of python from 2.6 to 3.x. Prior to this Stem did a 2to3 export when you installed it to provide cross-version compatibility. For users, the benefit of Foxboron's overhaul is that python3 installation and test runs are now much, much quicker. -------------------------------------------------------------------------------- Beside these a few other noteworthy tasks were... * Nick had a handful of suggestions for testing improvements, neatest of which was to include the command to re-run just individual tests when we have a failure. (#14113) * Our port_usage() function always returned None. (#14046) * Proc connection resolution could fail on busy systems. (#14048) * Fixed how the 'strict' argument works with exit policies. (#14314) Cheers! -Damian

1 0

Feature freeze schedule for Tor 0.2.6
by Nick Mathewson 31 Jan '15

31 Jan '15

Hi! Here's my plan for the Tor 0.2.6 feature freeze. I had hoped to to the freeze today, but I'm going to be travelling to a kid's birthday party for most of the day. So instead, I'm aiming for *Monday* for merging all features that are done, and giving possible extensions to high-value features that aren't yet implemented, but which aren't too far away. Until Feb 17, I'll take bugfixes and features that got extensions. After that, the only bugs I want to merge fixes for are: * bugs that have trivial obvious fixes * regressions * significant security bugs. (Note that the absence of a feature is not a bug). I hope this will let us get 0.2.6 stabilized in March. I'm planning to open an 0.2.7 development branch in early March one way or another. I'm going to write another email or blog post or something about all the cool stuff that's going into Tor 0.2.6 (and some of the stuff that I hope will go into 0.2.7) -- the development team has done a really excellent job, and I'm really happy with how well we've all been working together. Special thanks to all the excellent volunteers as well. best wishes, -- Nick

1 0

Re: [tor-dev] [Cryptography] traffic analysis
by grarpamp 27 Jan '15

27 Jan '15

On Tue, Jan 27, 2015 at 3:23 PM, Ben Laurie <benl(a)google.com> wrote: > Yeah, but ... who can realistically afford that bandwidth? One can afford what they wish to give to and thus expect to get from the network in return, no more, no less, as always. (Be it literally from the physical NIC network, or the logical networks created by their applications riding over and within the physical.) > To every possible recipient? Clearly you have to make a tradeoff. Full meshing of chaff addressed to all participants seems unnecessary. > grarpamp wrote: > Is there so much (possibly far less than correct) thought out there > that fill bandwidth is evil, untolerable, unmanageable, and blocking > of usability such that these networks are moot to even try coding > for general deployment? On Tue, Jan 27, 2015 at 1:35 PM, Jerry Leichter <leichter(a)lrw.com> wrote: > Google Fiber offers 1Gb/second - but how many customers running all > out will overload any possible backbone behind the single link from the > house to the concentrator? > > If everyone starts sending constant cover traffic, links will be quickly > overloaded all over the place. At which point the providers will start > charging [...] nobody will be happy That's the simple man's kneejerk response when initially contemplating chaffed networks. > There's room to do much better. For one thing, you don't need to saturate your link with cover traffic - you need to send enough cover traffic so that a listener can't tell the difference between cover and real traffic. This depends on if you're network is a low latency one, or if it uses a store and forward model. Even that is tricky due to needs to hide the size of data each endpoint exchanges from passive adversaries. It begins to approach constant higher rate the more you data wish to pass securely. > If your cover traffic rate equals your average rate over some period of time, > you're not adding more traffic - you're simply replacing some of your cover > messages with real messages. But ... what happens when you have a > peak demand way above your average? Then you must wait until you can pass your wheat. Or plan your needs according to the give and get model. > As Stealthmonger has commented concerning anonymity, if you want > security against traffic analysis, you have to accept delays: Set your > cover traffic rate somewhat higher than your average rate, and you'll > *eventually* catch up with peaks (though as with any queueing system, > the delays can grow without bound - requiring unbounded memory > *somewhere*). Delays (trading latency) are not the only way to achieve security. You may also elect to trade available throughput bandwidth in a wheat/chaff system. > I'm not aware of any open research on these kinds of questions - though > it may well be out there. What's the optimum cover traffic rate under > various assumptions about the real traffic rate and distribution? When > is it safe to use the traffic other users present as cover for your own? > Clearly if there's only one other user sending traffic, you can't use him > for cover as *he* can tell which of the packets are yours. But is there a > way to mix traffic from multiple users in a way that requires large numbers > of them to conspire to reveal anything? The mixmaster stuff looks at this > specifically from the point of view of a store-and-forward node - is there > some suitable useful analogue on a single link? Can we somehow get > the same guarantees without storage inside the network? There were some research references posted in the threads below. > we're now going to have to change our attitudes toward traffic analysis. Yes, a lot of oppurtunity exists to create new working networks in this area that utilize fill traffic and/or delay. You may want to review the recent guardian-dev and tor-dev side threads below on this exact subject of link padding, latency and analysis. Relavent papers and talk have been posted. https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004040.html https://lists.mayfirst.org/pipermail/guardian-dev/2014-November/004069.html https://lists.torproject.org/pipermail/tor-dev/2014-November/007741.html https://lists.torproject.org/pipermail/tor-dev/2014-December/007934.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008039.html http://www.metzdowd.com/pipermail/cryptography/2015-January/024479.html https://lists.torproject.org/pipermail/tor-dev/2015-January/008099.html [Copied a few places simply to include these ongoing links as reference for anyone interested.]

1 0

Regarding contributing to torproject
by Vipul Sharma 27 Jan '15

27 Jan '15

Hello developers, I have some experience in Python/Django and looking to contribute to torproject. I've read about many projects mentioned at: https://www.torproject.org/getinvolved/volunteer.html.en#Projects but still I need your help and advice to pick a project. Please suggest me which project should I look for, considering that I am new to torproject :) Apart from this, there are few questions I would like to ask: - Which is the best place to ask questions: mailing list or irc(#tor-dev) (I don't want to spam with my questions in this mailing list) ? - How should I communicate or notify before sending a PR ? - Is it necessary to issue a ticket before sending a PR ? (Supposing that I've found an issue) I know these are pretty novice questions but I need your help :) Regards, Vipul Sharma

1 0

Reminder for weekly OONI dev meeting Monday 2015-01-26 18:00 UTC (19:00 CET)
by Arturo Filastò 26 Jan '15

26 Jan '15

Hello Oonitarians, This is a reminder that today there will be the weekly OONI meeting. It will happen as usual on the #ooni channel on irc.oftc.net at 18:00 UTC (19:00 CET, 13:00 EST, 10:00 PST). Everybody is welcome to join us and bring their questions and feedback. See you later, ~ Arturo

1 0

Stem descriptor lazy loading
by Damian Johnson 25 Jan '15

25 Jan '15

I've been wanting to do this for years. Just a quick announcement that Stem now lazy-loads descriptors, giving it a nice performance boost... Server descriptors: 27% faster Extrainfo descriptors: 71% faster Microdescriptors: 43% faster Consensus: 37% faster For details see... https://gitweb.torproject.org/stem.git/commit/?id=3dac7c5 Note that descriptor validation is now opt-in rather than opt-out, so if you'd prefer validation over performance you'll now need to include 'validate = True'. This is a pretty big overhaul so please let me know if you run into any issues. Cheers! -Damian

1 0

Error while deploying tor-weather
by Vipul Sharma 25 Jan '15

25 Jan '15

Hello developers, I am trying to deploy tor-weather by following the installation instructions (given in INSTALL) and the steps given in its README. But it is giving an error: *IOError: Failed to read authentication cookie (permission denied): /var/run/tor/control.authcookie* Please can anyone help me. I am a student and new here :) Also, can anyone please tell me how should I communicate or notify before sending a PR ? Regards, Vipul Sharma

3 2

RFC: Tor Messenger Alpha
by Sukhbir Singh 25 Jan '15

25 Jan '15

Hi, Tor Messenger is an instant messaging client currently under development. It is designed to make connections using the Tor network and will therefore be a valuable piece in the privacy-enhancing software toolkit (web: Tor Browser, email: Thunderbird + TorBirdy, chat: Tor Messenger.) Based on the Instantbird IM client [0], Tor Messenger: - sends all traffic over Tor, - uses Off-the-Record (OTR) encryption [1] of conversations by default, - can be used with a wide variety of chat networks, - has an easy-to-use graphical user interface localized into multiple languages. Some more information about Tor Messenger (and why we picked Instantbird) can be found on the wiki [2]. Current Status We have Tor Messenger bundles for Linux (32-bit and 64-bit) with OTR (using ctypes-otr [4]) and Tor support (Tor binary and Tor Launcher included), among other privacy settings. We are doing automated builds of Tor Messenger using rbm [5] (thanks to Nicolas Vigier). @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ Bundles Linux (32-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/tor-messenger-0.… Linux (64-bit) https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/tor-messenger-0.… sha256sum https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/sha256sums.txt https://people.torproject.org/~sukhbir/tor-messenger-0.0.4/sha256sums.txt.a… The bundles are signed with my key (Sukhbir Singh; 0xB297B391). Extract the bundles and then run: ./start-tor-messenger. This is an early release and there may be serious privacy leaks and other issues -- please DO NOT recommend Tor Messenger to end users; this release is only for developers and advanced users who would like to help us with testing but understand the risks involved with using alpha software. Do not ignore this warning. We will try to have a monthly release cycle leading up to a stable release by July 2015. @@@ WARNING: NOT READY FOR PUBLIC USE. DO NOT DISTRIBUTE. @@@ Feedback With this release, we invite feedback not limited to anonymity leaks, usability issues, feature requests and suggestions for improvement. Please submit your feedback using the bug tracker [3] (select the "Tor Messenger" component). You can also talk to us on this mailing list or on IRC. (No seriously, don't use the bundles for any serious communication yet.) [0] - http://instantbird.com/ [1] - https://otr.cypherpunks.ca/ [2] - https://trac.torproject.org/projects/tor/wiki/doc/TorMessenger [3] - https://trac.torproject.org/projects/tor/newticket [4] - https://github.com/arlolra/ctypes-otr [5] - http://rbm.boklm.eu/ Thanks, Arlo Breault and Sukhbir Singh

5 5