- tor-dev - lists.torproject.org

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 01 Jun '14

01 Jun '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

Re: [tor-dev] tor-dev Digest, Vol 40, Issue 37
by 8106501726＠txt.att.net 30 May '14

30 May '14

Stop -----Original Message----- From: <tor-dev(a)lists.torproject.org> Sent: Fri, 30 May 2014 12:00:02 +0000 To: 8106501726(a)txt.att.net Subject: tor-dev Digest, Vol 40, Issue 37 >Send tor-dev mailing list submissions to > tor-dev(a)lists.torproject.org > >To subscribe or unsubscribe via the World Wide Web, visit > https://lists.torproject.org/cgi-bin/mailma ================================================================== This mobile text message is brought to you by AT&T

1 0

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

28 May '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 May 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. -- Nick

1 0

Code Review: or-applet
by Damian Johnson 27 May '14

27 May '14

Hi Yawning, I just took a quick peek at your or-applet (https://github.com/Yawning/or-applet) Nice work! Added it to Stem's examples page. Just a few thoughts. Nothing very substantial... > def _format_status(status): > if status == CircStatus.LAUNCHED: > return 'LAUNCHED (circuit ID assigned to new circuit)' > elif status == CircStatus.BUILT: > return 'BUILT (all hops finished, can now accept streams)' > elif status == CircStatus.EXTENDED: > return 'EXTENDED (one more hop has been completed)' > elif status == CircStatus.FAILED: > return 'FAILED (circuit closed (was not built))' > elif status == CircStatus.CLOSED: > return 'CLOSED (circuit closed (was built))' > return str(status) Very minor thing but I'd probably opt for the following... FORMAT_STATUSES = { CircStatus.LAUNCHED: 'LAUNCHED (circuit ID assigned to new circuit)', CircStatus.BUILT: 'BUILT (all hops finished, can now accept streams)', CircStatus.EXTENDED: 'EXTENDED (one more hop has been completed)', CircStatus.FAILED: 'FAILED (circuit closed (was not built))', CircStatus.CLOSED: 'CLOSED (circuit closed (was built))', } def _format_status(status): return FORMAT_STATUSES.get(status, str(status)) Ditto for the rest of the status_icon.py functions. > def _build_dynamic_menu(self): > circuits = self._ctl.get_circuits() > if circuits == None: > item = Gtk.MenuItem('No circuits established') > item.set_sensitive(False) > self._menu.append(item) > return > streams = self._ctl.get_streams() The get_circuits() method will never return None as you're using it here. It'll either return a list or raise a stem.ControllerError. I think what you actually want is... circuits = self._ctl.get_circuits(None) That way it'll return None rather than raise an exception if it fails. > our_streams.append('[' + stream.id + ']: ' + stream.target) In python string concatenation is discouraged unless it gives you readability benefits. It's slightly more performant to use format() or the following... our_streams.append('[%s]: %s' % (stream.id, stream.target)) That said, really doesn't matter. :) > if len(our_streams) == 0: > ... The boolean value of an empty list is False, so this is usually done as... if our_streams: ... > if self._control == None: Minor thing but None comparison is the one time it's suggested that you use the 'is' keyword (ie, 'if self._control is None:'). > class PopupMenu: It's generally a good idea to always extend object... class PopupMenu(object): > def is_newnym_available(self): > if self._control == None: > return False > return self._control.is_newnym_available() Hmmm, a goal I had for stem Controller objects was that they could be gracefully disconnected and reconnected. The Controller's is_newnym_available() already checks is_alive() and returns False if you're disconnected from tor. Ideally self._control should never be None. However, if you've never had an *initial* tor connection then I'm not sure that it's possible to instantiate a Controller. If so then that's a stem issue I'll need to think about... Cheers! -Damian

1 0