- tor-dev - lists.torproject.org

GSoC: BridgeDB Twitter Distributor report
by Kostas Jakeliunas 11 Jun '14

11 Jun '14

Hey all, in the past weeks I've been working on understanding what can be done using Twitter APIs and its media support in its CDN (for a later captcha implementation), as well as on improving my existing Twitter bridge distributor bot PoC. I've written some broken code, but it's alright. More details below. Distributor bot improvements included working on adding a churn rate control mechanism which securely stores Twitter user IDs (with code and design ideas from BridgeDB's HMAC approach to remembering e.g. email addresses in the EmailDistributor), and implementing a (mostly) bogus text-based challenge-response system (this is mostly so that we have a generic design for doing challenge-responses in this distributor - we'll be able to later on replace it with a decent CAPTCHA, for example. It's just nice to have a generic system and a thing for testing out the bot, etc.) I've also looked into using isis' new and shiny BridgeRequest objects to process user (well) 'bridge requests' in a non-hacky way; this should also eventually result in a bridge request syntax compatible with (a subset of) GetTor commands. But I still need to figure out the best way to use BridgeRequests, so nothing interesting to show yet. TODO * (still yet to) summarize a nice meeting i've had with sysrqb and isis. No definite conclusions were made, but there were (iirc) some nice ideas about a generic BridgeDB API that could be used by third party components, etc. (i.e. it might be worth pursuing it even if the Social Distributor is to be implemented at some later point.) * clean up my mess, test new code not to fail, and push new things onto https://github.com/wfn/twidibot/ (current (old) code there does work, if anyone's curious to run it) * figure out BridgeRequests, the new IRequestBridges (ha!) interface, and use these in the twitter bot * be able to 'serve' the bot fake bridge data so it could process it in a way that may be compatible with a future BridgeDB API (i.e., hopefully this bot will be able to run as a third-party-thing, separate from core bridgedb. This is hopefully how future distributors will/should work.) This way the bot will be more/actually 'realistic' in the way it serves current bogus bridge lines to users. (I thought I'd have this by now, but I don't. Hrm.) * continue looking into captcha systems modulo what can be used in the twitter context * look into bridgedb buckets and what I can help re: them, so the bridgedb API could happen sooner than later. (Old todo list item, did not yet touch it.) All in all, need to write more non-broken code, fewer words, and just continue with the current bot. Have a nice day/night/thing! -- Kostas. 0x0e5dce45 @ pgp.mit.edu

1 0

[GSoC 2014] Revamp GetTor: Send HTTP links for downloading TBB
by Israel Leiva 10 Jun '14

10 Jun '14

Hi! I've been discussing with my mentors (Sukhbir and Nima) the option of sending HTTP links to download TBB via GetTor. The main reason for this would be that in some censor countries is very difficult to download a "big file" (>= 10 Mb) over SSL, so HTTP links would be needed. Obviously, the user would be warned about the lack of SSL and that he/she *must* verify the integrity of the bundle. On the other side, bundles downloaded over HTTPS should also be verified if you need maximum security, since we can't trust in the cloud services neither. (e.g. Dropbox). Since this is not an easy decision, we've decided to discuss it publicly. Any thoughts on this? What's your experience regarding this matter? All feedback is welcomed. In the meanwhile we'll keep considering HTTPS links only. Regards. -- israel

2 2

GSoC: Multicore daemon status report
by Белоус Михаил 10 Jun '14

10 Jun '14

Hi all, As start of my project, I made patch to work queue, making thread pool more efficient and wrote some benchmarks. Future work 1.Rewrite architecture of tor circuit processing, to use thread pool 2.Write benchmarks showing, that multi core implementation efficient, or not? Most of my work can be found at https://github.com/towelenee/tor. Please feel free to provide feedback of any sort. Cheers, Mikhail

1 0

[announce] Tails HackFest, July 5-6, Paris
by intrigeri 08 Jun '14

08 Jun '14

Hi, I'm looking forward to see quite a few of you there! Join us at the Tails HackFest, 2014! July 5-6, 2014 -- Paris, France Description and goals ===================== Join us to make online anonymity and digital privacy usable by the masses! Whether you're a writer, a software developer, a designer, a system administrator or just plain interested, come learn about the challenges faced by Tails, and how you can be part of the solution. The Tails HackFest will bring together anyone interested in making Tails more usable and more secure. This open event will be an intense mix of teaching, drawing, coding, sharing, learning and celebrating. Logistics ========= * Where: the venue for the event is IRILL, Paris, France (https://www.irill.org/about/information-for-guests) * Dates: Saturday, July 5, 2014 - Sunday, July 6, 2014 * Time: 10 AM - 10 PM * Registration: if you want to attend, please consider dropping us a note about it. This is optional, but would help organizing this event. * Contact: <tails-hackfest-2014(a)boum.org>, #tails-hackfest on irc.oftc.net * Details, scheduling and updates: https://tails.boum.org/blueprint/HackFest_2014_Paris/ Host and sponsors ================= Many thanks to Debian, IRILL, Mozilla and the Tor project for supporting this event! Cheers, -- intrigeri | GnuPG key @ https://gaffer.ptitcanardnoir.org/intrigeri/intrigeri.asc | OTR fingerprint @ https://gaffer.ptitcanardnoir.org/intrigeri/otr.asc

1 0

Re: [tor-dev] Introducing CollecTor
by Karsten Loesing 08 Jun '14

08 Jun '14

[Replying on list with Damian's permission.] On 06/06/14 17:21, Damian Johnson wrote: >> I'm currently extending metrics-lib to fetch descriptors from CollecTor. >> Maybe Damian extends Stem to do the same (or accepts patches for that >> purpose). > > Probably obvious, but what's the advantage of this over fetching new > descriptors from authorities and mirrors? What kind of CollecTor > methods did you have in mind? If you're only interested in new descriptors, then the authorities and mirrors are the place to go. But if you care about having the full history of descriptors, then you should go to CollecTor. Imagine that your tool might break for a few hours. There's no way to get the missing data from the directory authorities or mirrors anymore. For applications like ExoneraTor, where you need to store every single consensus, this can make the difference. The same holds for Onionoo and the metrics website, though it's less critical to miss a few hours. Also, if you only care about relay descriptors, then you should be fine asking directory authorities and mirrors. But sanitized bridge descriptors, exit lists, bridge pool assignments, and Torperf measurements are only available from CollecTor. Note that there's also a disadvantage of fetching from CollecTor: it's a single point of failure. Now, we could add mirrors, but it would be even better to set up a second CollecTor instance (ideally run by another person) in parallel to the current first instance, and have the two exchange data. Future work, on my list. I guess the above should be added to the CollecTor homepage. Do you have any suggestions where you would have expected to read about this, or do you have further points to add? I'll add something next week. All the best, Karsten

1 0

[GSoC] Consensus Diffs - First report
by Daniel Martí 08 Jun '14

08 Jun '14

Hello everyone, This is my first status report regarding my GSoC project, Implementing consensus diffs. We weekly meetings with Nick and Sebastian, my mentors, every Wednesday at 14h UTC, if you want to take a closer look at the project's progress or want to participate. In the application timeline I specified that I would spend the first weeks coding the server side part, which is mostly just the generation of diffs. And that's what I've been doing thus far. I'm a bit behind on schedule due to exams, but I'm not too far off. I first implemented a dynamic algorithm, quadratic in both time and space, which seemed to work fine. Of course it didn't work for consensuses, since that would mean an allocation of nearly 3GB. So the next thing I did was switching to Hirschberg's algorithm, which still takes quadratic time but only takes linear space due to a divide-and-conquer approach. But that still leaves us at a horrible 16 seconds of runtime to generate a regular microdescriptor consensus diff, whereas 'diff -d' only takes a fifth of a second. That is largely due to the fact that we're not taking advantage of the consensus properties yet. So what I will do next is improve the algorithm, which should make it very close to linear in time. The idea is to navigate the two consensuses, looking at the digests that will already be sorted for us. That's part of the 'r' line for descriptor consensuses, and the 'm' line for microdescriptor consensuses. This should take linear time. Now, the part of Hirschberg's algorithm that makes it quadratic in time is finding 'k', the column at which the problem can be split in half wihtout losing precision. This is well explained here: http://wordaligned.org/articles/longest-common-subsequence But once we are navigating the nodes ordered by digests, we can avoid having to calculate 'k'. Given that we are at any pair of matching digests, we can assume that this is already a point 'k' because all the nodes that are before the digest on the first consensus can only be found before the digest on the second consensus, and the same goes for later digests. So the final algorithm should travel both consensuses in linear time, and use our quadratic time algorithm on the small chunks between these matching digests. The quadratic time algorithm would at worst be used for maybe a couple hundred lines, a size at which it still performs fairly well. You may be wondering why I went with an O(MN) algorithm when I could have gone with the more common O(ND) algorithm, which I understand is the one used in the GNU diffutils. The main reason is the use-case. O(ND) performs worse than O(MN) when the differences are large, because then D=2N. In our case, when we are running the algorithm it's because nodes disappeared, appeared or simply to find changes in nodes that are still there. So it will be very common that we find diffs D that are very close in size to N or M. Plus, as far as I understand, the divide-and-conquer algorithm is pretty clean and easy to understand while the O(ND) algorithm by Myers would probably be harder to implement in a clean way. I'm in no way an expert in diff/lcs algorithms, so suggestions and comments are very welcome. -- Daniel Martí - mvdan(a)mvdan.cc - http://mvdan.cc/ PGP: A9DA 13CD F7A1 4ACD D3DE E530 F4CA FFDB 4348 041C

1 1

DetecTor Review
by Damian Johnson 07 Jun '14

07 Jun '14

Hi Kai. I just took a quick peek at your DetecTor project (http://detector.io/) It looks like the project has been inactive for a while so just some quick thoughts in case it sparks back up. > log_setting = "notice file " + data_dir + os.sep + "tor.log" The following might be nicer... log_setting = "notice file %s%stor.log" % (data_dir, os.sep) Same goes for most instances of string concatenation, actually. > 'StrictExitNodes': str(1), Interesting, never seen this before. Should be the following instead. 'StrictExitNodes': '1', > def stop_tor(control_port): > tor_pid = stem.util.system.get_pid_by_port(control_port) > if tor_pid: > os.kill(tor_pid, signal.SIGTERM) Certainly a fine approach. Would you like to avoid having Tor outlive this python process? If so then that's as easy as including 'take_ownership = True' in your launch_tor_with_config() call. If not then you can use the process object returned by launch_tor_with_config() to kill it as well... tor_process = stem.process.launch_tor_with_config() ... do stuff... tor_process.kill() Also this method has tabs mixed with spaces. I would highly recommend strictly using spaces - python is whitespace dependent, and occasional tabs can make things a lot more confusing. > def is_tor_running(control_port): > return bool(stem.util.system.get_pid_by_port(control_port)) I believe you can use the poll() method of the process object to make this a little less platform dependent. > if os.path.isdir(dir_name) != True: You never need to compare with booleans in an if statement. This is equivalent to... if not os.path.isdir(dir_name): > config.readfp(open('sphere_control.config')) Minor thing but this doesn't properly close the file handle. It's probably done on its own during GC, but it would be more proper to do... with open('sphere_control.config') as config_file: config.readfp(config_file) Honestly I'm really not sure what the following code is doing. I suspect there's a lot of low hanging fruit for improving this (for instance using "', '.join(countries_list[i])" instead of tracking a 'countries_string') but first step would be some comments explaining what this is trying to achieve. Cheers! -Damian

1 0

GSoC : Rewrite Tor Weather (Status Update 1)
by Sreenatha Bhatlapenumarthi 07 Jun '14

07 Jun '14

Hi all, So here is my first update on the work regarding weather rewrite. 1. (#12085) Develop python wrapper for Onionoo services. Made an initial python wrapper to be used for fetching Onionoo documents. It currently supports request-response caching to decrease the latency(picked up from OnionPy). 2. (#11956) Wrote a simple script for searching for relays matching user's query. This functionality is to be implemented in the rewritten weather as well. Modified it to use the new Onionoo wrapper instead of 'urllib' module for fetching response from Onionoo. 3. (#9889) Rewrote the previous tshirt script, making use of the new Onionoo wrapper. Future work 1. Add and expand the features provided by the Onionoo wrapper. Currently in the process of adding utility methods for backend scripts that use Onionoo data. 2. Test the Onionoo wrapper 3. Write the remaining backend scripts(hourly, daily) etc described in the wiki at https://trac.torproject.org/projects/tor/wiki/doc/weather-in-2014 Most of my work can be found at https://github.com/lucyd/tor-weather. Please feel free to provide feedback of any sort. Cheers, Sreenatha

1 0

Pluggable Transport Combiner Status Report 1
by quinn jarrell 07 Jun '14

07 Jun '14

Hi everyone, I'm the GSoC student working on the the Pluggable Transport Combiner. So here's what I've been working on: - I added in a configuration class and file reader to obfs-flashproxy client. - The obfs-flashproxy client can now launch any number of transports in a row. - It chains together the pluggable transports with SOCKS servers What I'll be working on next: - Documentation on the design - Making the combiner intercept the first tor connection instead of recieving the first pt's output as it does now - Testing authenticated transports. If you've got any questions or comments shoot me an email! Quinn Jarrell

2 1

GSoC Stegotorus update 1
by Noah Rahman 07 Jun '14

07 Jun '14

- Progress so far 1) Fixed segfaulting refactored SWF steganographic code. Code now fails on decompression but at least it's not segfaulting anymore. Suspected it was due to how trace payload server is integrated and rest of problems should be fixed by reimplementing pre decompression logic that was lost in refactored-away SWF_receive code. Can then move on to JS 2) Added config file for options using inih library, still testing locally. 3) With Yawning' s help, began to replace Moeller handshake with libelligator implementation. (#8089) Goals for next update 1) Finish SWF refactoring and associated unit test, start on JS 2) Finish elligator handshake and write unit test for config file. Test with ctgrind when I figure out how to patch valgrind properly. 3) Meet with Vinod at SRI and determine most expedient way of merging SRI changes into Stegotorus build (meeting scheduled for next Friday the 13th) Best Noah R.

1 0

Orbot & Orfox - Bi-weekly report
by Amogh Pradeep 06 Jun '14

06 Jun '14

Hey all, Attached to this email is my bi-weekly report on the project Orbot and Orfox.

1 0

[GSoC 2014] Revamp GetTor status report #1
by Israel Leiva 06 Jun '14

06 Jun '14

Hi all! This is the first status report for the Revamp GetTor GSoC project. I'll try to summarize what has been done. For more details feel free to ask. If you have comments, please tell me. Achievments: * Decided to rewrite the code. Made a proposal for a new GetTor's design. Available at [0]. * Discussed this new design with my mentors. Several changes has been made since its original version, including the use of ConfigParser for reading the links files. * Improved Python knowledge. Read PEP8 and PEP-0257 to (try to) create standard code. * Created the basis of the Core module, including a dummy script to test it. It can successfully read links from files and display them on screen. Available at [1]. Goal(s) until next report: * Have the Core module working with _at least_ one provider (Dropbox). This means adapt the current dropbox script to the new design. All of this properly documented and as standard as possible. That's all for now. Have a nice weekend! [0] https://github.com/ileiva/gettor/tree/master/spec [1] https://github.com/ileiva/gettor/tree/master/src -- israel

1 0

Get the latest TBB
by Israel Leiva 06 Jun '14

06 Jun '14

Hi all! Is there a better way to get a link for the latest TBB rather than looking at https://www.torproject.org/dist/torbrowser/? I'm thinking on something easy to automate (for the Revamp GetTor project). Thanks! -- israel

3 4

Proposal 236, Single-guard designs, and directory guards
by Nick Mathewson 06 Jun '14

06 Jun '14

Hi, all! I noticed that proposal 236 doesn't mention directory guards. (See proposal 207, implemented in Tor 0.2.4.) I think that we should consider retaining multiple directory guards while going to a single guard for multi-hop circuits. My rationale here is that when we have only a single directory guard, it can more easily perform hard-to-detect route biasing attacks by pretending not to have descriptors for nodes it doesn't like. Its ability to do this is limited by fact that we won't build circuits unless 95% of all paths are buildable (see get_frac_paths_needed_for_circuits() and its users). But still, trusting a single source for the completeness and freshness of your directory info is suboptimal. I also think that most of the arguments for single-guard apply to circuit guards more than to directory guards. But there could be some left, and we should figure those out. peace, -- Nick

5 6

Pluggable transports meeting today (Friday 6th of June 2014)
by George Kadianakis 06 Jun '14

06 Jun '14

Hello friends, just wanted to remind you that the regular biweekly pluggable transports meeting is going to occur today at 16:00 UTC. Place is the #tor-dev IRC channel in the OFTC network. Please note that we recently *changed* the time from 17:00 to 16:00 UTC. Thanks!

1 0

[Patch] test/test.c. TEMP-dir
by Gisle Vanem 05 Jun '14

05 Jun '14

Hello list. I don't get any FAILED tests running on Win32 (MSVC), but IMHO the use of '\\' in the TEMP-directory doesn't look quite kosher (looks a bit like a "\\server\share\path" UNC-syntax). >From test_crypto_pk() running 'test.exe --warn': Jun 05 10:13:05.046 [warn] Could not open "F:\TEMP\\tor_test_3992_vv7drny6/xyzzy": No such file or directory Jun 05 10:13:05.046 [warn] Error reading private key from "F:\TEMP\\tor_test_3992_vv7drny6/xyzzy" So can you accept this small change: diff --git a/src/test/test.c b/src/test/test.c index 8bce9c9..98620e5 100644 --- a/src/test/test.c +++ b/src/test/test.c @@ -108,9 +108,9 @@ setup_directory(void) const char *tmp = buf; /* If this fails, we're probably screwed anyway */ if (!GetTempPathA(sizeof(buf),buf)) - tmp = "c:\\windows\\temp"; + tmp = "c:\\windows\\temp\\"; tor_snprintf(temp_dir, sizeof(temp_dir), - "%s\\tor_test_%d_%s", tmp, (int)getpid(), rnd32); + "%stor_test_%d_%s", tmp, (int)getpid(), rnd32); r = mkdir(temp_dir); } #else ------------------ Ref: http://msdn.microsoft.com/en-us/library/windows/desktop/aa364992(v=vs.85).a… lpBuffer [out] A pointer to a string buffer that receives the null-terminated string specifying the temporary file path. The returned string ends with a backslash, for example, "C:\TEMP\". ---------- I also tested 'test.exe --warn' without any TMP or TEMP. Thus my USERPROFILE is used: Jun 05 10:46:47.984 [warn] Could not open "f:\Documents and Settings\Gisle Vanem\tor_test_6368_s62ks2fe/xyzzy": No such file or directory Jun 05 10:46:47.984 [warn] Error reading private key from "f:\Documents and Settings\Gisle Vanem\tor_test_6368_s62ks2fe/xyzzy" --gv

1 0

Reminder: tor development meetings this (and every) Wednesday, 19:00 UTC
by Nick Mathewson 04 Jun '14

04 Jun '14

Hi, all! Here's your regular reminder for the weekly IRC meeting for people working on the program "tor". (This won't cover all the other programs developed under the Tor umbrella.) The next meeting time will be: Wednesday June 28, 19:00 UTC. (That's 3pm EDT and 12:00 noon PDT.) As usual, we'll do it on the #tor-dev IRC channel. I've seen a drop-off in the number of people coming since I stopped sending these out weekly, so I'm sending them again for a while. Among other stuff, I expect we'll be figuring out the rest of the 0.2.5 series, planning an 0.2.5.5 release maybe trying to chase some bugs, and figuring out how to open development on 0.2.6.x. cheers, -- Nick

3 3

tor-weather meeting Wed, 1800UTC
by meejah 03 Jun '14

03 Jun '14

Wednesday, 1800UTC, #tor-dev I will run the meeting. I haven't made MeetBot run anywhere; if someone has an instnace we can try out tomorrow, please mail me or follow-up here. If you have something to add to the agenda, either mail me directly or just show up at the meeting (we will figure out the agenda as the first thing). thanks, meejah

1 0

obfs4 and ntor (question wrt node_id)
by George Kadianakis 02 Jun '14

02 Jun '14

Hello Ian, hope you are well :) I have a question wrt a new PT and ntor. Yawning Angel has been developing a new PT called obfs4 (temp name), which is basically scramblesuit using ntor and elligator2. This results in better performance than UniformDH. You can find the spec of obfs4 here: https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt You can read a description of the ntor handshake here: https://github.com/Yawning/obfs4/blob/master/doc/obfs4-spec.txt#L149 The protocol works fine, but it requires two shared-secrets between the client and the server. The first is the long-term public key of obfs4, and the other is the "node id" of the server (defined as fingerprint of the bridge's identity key). My question has to do with the "node id" (denoted as 'capped B' in the ntor paper) . The problem is that it complicates the deployment of obfs4, since the bridge operator has to find her bridge's fingerprint (by looking at $DataDirectory/fingerprint) and add it to her torrc (as part of the ServerTransportOptions line). Also, the bridge operator needs to give a similar Bridge line to her clients. I was trying to understand if it's possible to simplify this, by not requiring the bridge operator to make the effort of finding her bridge's fingerprint. There are at least two possible ways to do this: a) Instead of using the bridge's identity key as the node id (which provides some kind of (unneeded?) channel binding), just generate a random string to serve as the node id of the bridge. As I understand it, node id is just a 1-1 map to a specific public key, so a big random string should be able to do the trick, right? b) Just discard the node id, and use the public key in its place. So wherever 'capped B' is used, just use 'B' instead. Intuitively this seems OK to me, but I admit I couldn't follow the whole security proof on Appendix B, to verify that it doesn't make any difference. Do you think any of the above approaches is correct, without bludgeoning ntor's security? Thanks!

3 3

Question about HS code
by Michael Rogers 02 Jun '14

02 Jun '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, I've been trying to get to grips with the hidden service code, and I have a question that I was hoping someone on the list could answer. The constant REND_HID_SERV_DIR_REQUERY_PERIOD is defined as 15 * 60 (15 minutes) in rendclient.c, with the comment "The period for which a hidden service directory cannot be queried for the same descriptor ID again." As far as I can tell, the purpose of this constant is to prevent a client from repeatedly asking an HS directory for a descriptor that the directory doesn't have. However, when a descriptor fetch fails and there's no reusable cached descriptor, rend_client_desc_trynow(query) calls rend_client_note_connection_attempt_ended(onion_address), which calls purge_hid_serv_from_last_hid_serv_requests(onion_address), which (as far as I can tell) forgets which HS directories have been tried for the descriptor, allowing the same directories to be tried again before REND_HID_SERV_DIR_REQUERY_PERIOD elapses. So what's the effect of REND_HID_SERV_DIR_REQUERY_PERIOD? Thanks for any guidance, Michael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEcBAEBCAAGBQJThJI1AAoJEBEET9GfxSfMHxwH/3DH2ZpWsmjfu8wX/Zaw2m1T 5NBYhrzpQqJ5C3doVd5cSsCuZINQOG/kHFda3HAf4a0UwANkGZQzSKiB78IXL/VG yEVts1ZpDEF3rtGgnQMBnFQ9JChNzYRuJ5uT+EFJBjW9fgWVuh+8KugNev9wLiR8 V8ayDaekZxUaT11+qEqS974IRI1wWVIzUvGFylMsCsuf/NAKkUalXscOOT3ckKUN g2b1M5f38uzpFqdvRtTIgL/p0dS3JtrrGcuYnwD2+THzeAQpIHGuFPxnbjoauCBd HwyGCo0v3UKr4e00YSKlhJBAZjB2Y41jwi5vasp7IefFvsuVOXfcc8b4BP5Syyk= =d/B4 -----END PGP SIGNATURE-----

2 2

Unit tests that need writing in core
by Ajay Bhat 02 Jun '14

02 Jun '14

Hi, I'd like to contribute to tor core by writing any unit tests that need to be done. Can anyone please help me out by pointing out the code/modules that needs to be tested? -Ajay

2 1

Damian's Status Report - May 2014
by Damian Johnson 02 Jun '14

02 Jun '14

Hi all, this month was focused on work leading up to today's Stem 1.2.0 release. The control interpreter in particular turned out extremely well, so if you haven't tried it yet then please check it out! https://blog.torproject.org/blog/stem-release-12 https://stem.torproject.org/tutorials/down_the_rabbit_hole.html Besides implementing and writing a tutorial for the interpreter this involved addressing a host of other issues that had accumulated in trac. By far the most important was an issue where Stem spawned Tor instances would halt due to unread stdout content (#9862). Last, I looked over the code of several new Stem users this month and added them to our examples page... * Yawning's or-applet (https://lists.torproject.org/pipermail/tor-dev/2014-May/006915.html) * Whonix (https://lists.torproject.org/pipermail/tor-dev/2014-May/006799.html) * Kostas' torsearch (https://github.com/wfn/torsearch) Cheers! -Damian

1 0

Stem Release 1.2
by Damian Johnson 01 Jun '14

01 Jun '14

Hi all. After months of work I'm please to announce the release of Stem 1.2.0! For those who aren't familiar with it, Stem is a Python library for interacting with Tor. With it you can script against your relay, descriptor data, or even write applications similar to arm and Vidalia. https://stem.torproject.org/ So what's new in this release? ============================================================ * Interactive Tor Interpreter The control interpreter is a new method for interacting with Tor's control interface that combines an interactive python interpreter with raw access similar to telnet. This adds several usability features, such as... * Irc-style commands like '/help'. * Tab completion for Tor's controller commands. * History scrollback by pressing up/down. * Transparently handles Tor authentication at startup. * Colorized output for improved readability. For a tutorial to get you started see... https://stem.torproject.org/tutorials/down_the_rabbit_hole.html ============================================================ * New connect() Function This release of Stem provides a new, even easier method for establishing controllers. Connecting to Tor can now be as easy as... import sys from stem.connection import connect if __name__ == '__main__': controller = connect() if not controller: sys.exit(1) # unable to get a connection print 'Tor is running version %s' % controller.get_version() controller.close() ============================================================ For a rundown on the myriad of improvements and fixes in this release see... https://stem.torproject.org/change_log.html#version-1-2 Cheers! -Damian

1 0

Improving Unit Tests Coverage with Sample Patch
by Clark Wood 31 May '14

31 May '14

Hello, I'm interested in volunteering some to help improve unit test coverage. Please find attached a small patch with unit tests for $TOR/src/or/cpuworker.c. I intend to do some more work for cpuworker's functions, but for now am curious about whether the "if (1)" block spanning lines 671-720 is needed. --Clark

1 0

wfpadtools: comments about primitives
by Marc Juarez 30 May '14

30 May '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, I am a GSoC student working in a new PT for the development of future Website Fingerprinting countermeasures in Tor. The PT is not targeting any specific defense, but to link padding defenses in general. The idea is to implement a set of primitives that any link padding-based defense would benefit of. In this email I provide a more detailed description of these primitives and give a short update about their state. I forked the obfsproxy repo and made it publicly available in bitbucket: https://bitbucket.org/mjuarezm/obfsproxy-wfpadtools. I would appreciate comments from the Tor development community. I'm specially looking for advices that help me generalizing the padding module (padutils) and comments about the primitives I describe below. The envisaged primitives are: 1. A general padding class that provides methods to pad the link This part is almost finished. For that I reused the Scramblesuit's probdist and fifobuffer modules to buffer and flush data according to a given probability distribution. Using this class I have implemented a simple version of BuFLO (which is also included in the padutils module). 2. Create a framing layer for the PT This layer would allows to signal padding messages so that they can be filtered out. I have to implement the protocol's message scheme so I can parse the flags in the header and get rid of the padding messages. 3. Implement the state machine of the basic padding protocol. BuFLO assumes that there exists a mechanism to detect the beginning and end visits. I would implement this using a new state in the protocol's state machine (ST_VISITING), but I still need to find a way to signal the beginning and the end of each visit. 4. Implement the protocol's handshake. I took a look to the Scramblesuit's handshake.The handshake of this protocol would boil down to the negotiation of the parameters (e.g., probability distributions) for the padding. 5. Implement a flow control protocol This would adjust the padding parameters while running. The fifobuffer we are currently using helps queuing the messages but we will need an extra logic to detect congestion. 6. Padding operations We will implement padding operations that might be handy for the future countermeasure. For example, one possible operation could be to specify the number of cells to send in response to a padding cell request. 7. A module to test protection against Website Fingerprinting This module would leverage the Peekaboo's framework by Dyer et al. (we may consider to extend it to include the newest Website Fingerprinting attacks). Best, - -- marc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTiKxFAAoJEGfJ5xfgazlxw70H/1EbzYOuhLwDe5xdLiz/Pn3z UrXV+GCPG+Wa3SiQOFqCqSKn9D/E0dwLLZKcG/zE9F8wZeSbtjlDIBn4NNUwMzz3 XMfCHcohxLHtKFwhTncHkTvEn6ZI1IzAUn1wCHdNWVGoTfVVuY5RtNKF0F0IxBBf IE1mEFoM1wKzmQIFvB/MkPlLo65Ilhwv20GHgqGwDpKXYwBROBHR7CLn29oL/GB8 lZWVm0ZeDB0wtqjdPqxh9g2nEoxQR83BzJHeos+fue1onnZw+L23gbzfIvznjuL5 47Yed3T4l1q1k1i56G96/CoBIFlBboKfz5WhJ0dnDz2p4s996BNNIazxNybenjU= =5LGv -----END PGP SIGNATURE-----

4 7