- tor-dev - lists.torproject.org

Comparing handshake protocols for Tor: Ace vs ntor
by Esfandiar Mohammadi 23 Jul '13

23 Jul '13

Hi, in WPES 2012 [2], Aniket Kate and me introduced Ace, an alternative for Tor's current handshake protocol ntor (which was also briefly discussed on this list [4]). Back then, no implementation for the double scalar multiplication operation (a * b + c * d) on Curve25519 was available. But recently, Robert Ransom implemented in his celator library [1] a highly efficient double scalar multiplication which is suitable for our handshake protocol Ace. In an internship with us, Shivanker Goel implemented and run comparative benchmarks of the Ace protocol, using Robert's celator library [1], and the current ntor implementation. Here are the benchmarks: 64-bit architecture: Ace: 401,129 cycles, ntor: 472,772 cycles, 32-bit architecture: Ace: 2,797,303 cycles, ntor: 5,179,069 cycles, About the benchmarks: * For cleaning the cache, the benchmarks runs the handshake 1000 times prior to starting the benchmarks. Then, we used a tsc_read() function to count the cycles, repeated the handshake 5000 times and computed the average of the cycles. * In order not to be forced to import too many functions from the Tor library, we do not use the function dimap_search, which looks up the secret key for a given public key, in the benchmarks. * We assume that ephemeral keys are precomputed, e.g., in idle cycles. In the benchmarks these ephemeral keys are received as an input. * For the benchmarks hyper-threading and overclocking were disabled and gcc-4.8 with "-O2" optimizations was used. The code is available online [2]. We also tried to formulate a tor-style proposal, which is also available online [3]. Any feedback, comments, or suggestions are welcome. - Esfandiar [1] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/celator.tar.gz [2] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-benchmarks.tar.gz [3] http://www.infsec.cs.uni-saarland.de/~mohammadi/ace/ace-handshake.txt [4] It was discussed in the thread "Another key exchange algorithm for extending circuits: alternative to ntor?" from August 2012.

1 0

Remote descriptor fetching
by Damian Johnson 23 Jul '13

23 Jul '13

Hi Karsten. I'm starting to look into remote descriptor fetching, a capability of metrics-lib that stem presently lacks [1][2]. The spec says that mirrors provide zlib compressed data [3], and the DirectoryDownloader handles this via a InflaterInputStream [4]. So far, so good. By my read of the man pages this means that gzip or python's zlib module should be able to handle the decompression. However, I must be missing something... % wget http://128.31.0.34:9131/tor/server/all.z % file all.z all.z: data % gzip -d all.z gzip: all.z: not in gzip format % zcat all.z gzip: all.z: not in gzip format % python >>> import zlib >>> with open('all.z') as desc_file: ... print zlib.decompress(desc_file.read()) ... Traceback (most recent call last): File "<stdin>", line 2, in <module> zlib.error: Error -5 while decompressing data: incomplete or truncated stream Maybe a fresh set of eyes will spot something I'm obviously missing. Spotting anything? Speaking of remote descriptor fetching, any thought on the API? I'm thinking of a 'stem/descriptor/remote.py' module with... * get_directory_authorities() List of hardcoded (IP, DirPorts) tuples for tor's authorities. Ideally we'd have an integ test to notify us when our listing falls out of date. However, it looks like the controller interface doesn't surface this. Is there a nice method of determining the present authorities besides polling the authorities array of 'src/or/config.c' [5]? * fetch_directory_mirrors() Polls an authority for the present consensus and filters it down to relays with the V2Dir flag. It then uses this to populate a global directory mirror cached that's used when querying directory data. This can optionally be provided with a Controller instance or cached consensus file to use that instead of polling a authority. * get_directory_cache() Provides a list of our present directory mirrors. This is a list if (IP, DirPort) tuples. If fetch_directory_mirrors() hasn't yet been called this is the directory authorities. * query(descriptor_type, fingerprint = None, retires = 5) Picks a random relay from our directory mirror cache, and attempts to retrieve the given type of descriptor data. Arguments behave as follows... descriptor_type (str): Type of descriptor to be fetched. This is the same as our @type annotations [6]. This raises a ValueError if the descriptor type isn't available from directory mirrors. fingerprint (str, list): Optional argument for the relay or list of relays to fetch the descriptors for. This retrieves all relays if omitted. retries (int): Maximum number of times we'll attempt to retrieve the descriptors. We fail to another randomly selected directory mirror when unsuccessful. Our last attempt is always via a directory authority. If all attempts are unsuccessful we raise an IOError. ======================================== I'd imagine this would make use of the module something like the following... # Simple script to print all of the exits. from stem.descriptor import remote # Populates our directory mirror cache. This does more harm # here than good since we're only making a single request. # However, if this was a longer living script doing this would # relieve load from the authorities. remote.fetch_directory_mirrors() try: for desc in remote.query('server-descriptor 1.0'): if desc.exit_policy.is_exiting_allowed(): print "%s (%s)" % (desc.nickname, desc.fingerprint) except IOError, exc: print "Unable to query the server descriptors: %s" % exc ======================================== Thoughts? Does this cover all of the use cases we'll this module for? Cheers! -Damian [1] https://trac.torproject.org/8257 [2] https://gitweb.torproject.org/metrics-lib.git/blob/HEAD:/src/org/torproject… [3] https://gitweb.torproject.org/torspec.git/blob/HEAD:/dir-spec.txt#l2626 [4] http://docs.oracle.com/javase/6/docs/api/java/util/zip/InflaterInputStream.… [5] https://gitweb.torproject.org/tor.git/blob/HEAD:/src/or/config.c#l780 [6] https://metrics.torproject.org/formats.html#descriptortypes

3 10

[GSoC '13] Tor status report - Searchable metrics archive
by Kostas Jakeliunas 22 Jul '13

22 Jul '13

Hey all, I apologize for this unusual timing for a status report, but I ended up delaying it beyond measure, so better now than later I guess. I can reiterate it + any updates soon, it's just that I figure I'm long overdue on informing tor-dev on what's going on. I've started my project [1] later than is usual, and more or less immediately ran into what I deemed to be a database / ORM scaling issue (the thing I'd been actually trying to avoid since writing the proposal), or at least a behaviour of the ORM which was suboptimal to what we have in mind: delivering (first and foremost) a searchable metrics archive backend/database which incorporates, as of current plan, server descriptors (relays and bridges, turns out a server descriptor model can happily service both) and server/router statuses across a few year timespan (currently using v3 consensus documents only), and provides querying functionality which can extract relations between the two. The 'querying with relations between the two' part, when tested on a broader span of data, seemed to be causing trouble to me. I ended up allocating probably inefficiently large amounts of time to this problem, rewriting the backend part, and trying to optimize the queries which underlied the ORM (turns out I didn't need to strip off the ORM abstraction - learned a few things about SQLAlchemy that way - I will follow-up with an email pointing to current code (sorry)). * The current iteration of the ORM model / backend (which actually is very simple) solves this problem. * Stem descriptor and network status mapping to ORM works, and is nicely (enough) integrated with the data import (from downloaded metrics archive) tools, as well as an API to make queries on the ORM. * Implemented a partial Onionoo-protocol-adhering (without compression and without some fields) backend for ?summary and ?details Onionoo queries. * Still tidying everything up. And *finally* writing a design document outlining what we actually ended up with, and what is required till full Onionoo integration. Code review will happen pretty soon, and hopefully we'll have some discussion upon where to go from here. Karsten mentioned that it might be possible to use the existing Onionoo incarnation to continue providing bandwidth weight etc. data (basically stuff from extra-info), and it might be possible to join the two systems into an Onionoo-supporting backend which will cover all / majority of archives available. Another (or) further avenue would be to continue with the initial proposed plan to extend the query format; and to build a frontend which would make use of the extended query format. Expect another email with links to (decent) code. [1]: http://kostas.mkj.lt/gsoc2013/gsoc2013.html

1 0

Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
by User of Tor 21 Jul '13

21 Jul '13

This was a HTML5 video. Thank you All for answers.

1 0

Problems. Flash plugin works by default! I can see youtube video with Tor Browser Bundle
by User of Tor 17 Jul '13

17 Jul '13

Hi, I've installed Tor Browser Bundle for Windows (tor-browser-2.3.25-2_ru) I didn't change any settings. When I visit any html-page on which there is a flash video i can see it, flash works! Why? It must not work! In settings(plugins) "Flash plugin" is disabled and it is inactive. In Tor Button settings Plugins are turned off. What happens? Is it a BUG? Regards.

5 4

TBB without Vidalia
by Zack Weinberg 15 Jul '13

15 Jul '13

How technically difficult would it be to remove Vidalia from an already-packaged TBB? (Ideally something that could be put into a shell script.) Basically what I want is a more-current-than-ESR10 browser that uses a system-installed & -configured Tor instance. I wouldn't miss the Torbutton UI, either (it should just use Tor all the time).

3 2

Status Report - Steganography browser addon a GSOC 2013 project
by Hareesan 14 Jul '13

14 Jul '13

Hi all, In last two weeks, I worked on detecting video and sound contents from web pages and get them as byte format to be used with algorithms later. To test it, use the test button in context menu over video element and it will alert the byte code of the content selected. ( Might take some time due to the video element file size). My next plan for coming weeks is to finish content uploading to extension from local memory. And more than context menus, all the content handling parts like toolbar button, menu buttons, upload options will be done by the end of coming two weeks. -- Hareesan

1 0

[GSOC] Status report - Tor capabilities
by Cristian-Matei Toader 13 Jul '13

13 Jul '13

Hello tor-dev, Here goes the status report for the past 2 weeks - I have been preparing the code for the first step of the project to be merged in the Tor master branch, which represented a number of changes required by nickm; the full process can be seen here [1], the branch was squashed and should be merged one of these days. - Step 2: - current progress - has changed a bit, and now requires to create a sandbox as 'tight' as possible around the Tor syscalls; - this is achieved my filtering not only syscalls but also syscall parameters, current efforts on my part can be found here [2] in branch "gsoc-cap-stage2"; - the current problem with this stage is filtering string parameters for syscalls which can be done using immutable strings using protected memory regions; - unfortunately some syscalls are out of reach being part of libraries and therefore their parameters cannot be controlled (the pointer used in the seccomp filter cannot be reference in the syscall) which will need to be solved (any suggestions are appreciated). - I have implemented ioerror's suggestion about policy files but is not pushed to git mainly because after talking to nickm we concluded that the implementation effort is not justified especially now when filter configurations are constantly changing which would require also changing how policy files are parsed, having mostly the same end result; furthermore some of the string filter parameters may be generated on runtime, which may be inconsistent with the solution, but I will keep this in mind towards the finishing stage of the development process, especially since it offers an elegant way of configuring and testing different filters. As a small side-note I will mostly be traveling the majority of next week, so I may not be as reachable as before. Looking forward to some feedback, if you happen to have any! References: [1] https://trac.torproject.org/projects/tor/ticket/9168 [2] https://github.com/cristiantoader/tor-gsoc-capabilities

2 1

Status report - Stream-RTT
by ra 12 Jul '13

12 Jul '13

Hi all! I started a little late on this years GSoC project[0] which is about reducing the RTT of preemptively built circuits. Since begin of July I have been working on scripts for Tor path generation and Stream-RTT probing. For the path generation script "path_finder.py" I decided not to reimplement Tor's path generation logic but to ask a Tor client to choose a path without actually building it. I have written two small patches for Tor which implement the following new control commands: -) "DUMPGUARDS" removes all entry guards. (This might also be handy to work around the path selection strangeness when guards are disabled[1]). -) "FINDPATH" tells the Tor client to generate a path but do not build a circuit from it. To verify the correctness of the approach I am currently generating a few million paths and will look into the distribution of nodes. The Stream-RTT-probing script "rttprober.py" is also in a working state. Though it needs some more testing, it is already able to spawn multiple threads where each builds a circuit and runs a number of probes on that circuit, measuring the RTTs of the stream and the circuit build time. I will hopefully be able to get useful Stream-RTT-data soon to tackle the first interesting questions. All scripts and patches are available online[2]. Best, Robert [0] https://www.google-melange.com/gsoc/project/google/gsoc2013/ra_/19001 [1] https://trac.torproject.org/projects/tor/ticket/9188 [2] https://bitbucket.org/ra_/tor-rtt

1 0

GSoC Status Report - EvilGenius
by Johannes Fürmann 12 Jul '13

12 Jul '13

Hi *, As the weekend approaches, it is time for my second status report on the censorship simulation project "EvilGenius". In the last two weeks I learned a lot about virtualization and the OONI project EvilGenius is being planned and written for. After fixing smoothing out some rough edges in the Vagrantfiles, I created the first 'censorship provider', i.e. a blueprint for a box that actually does censorship, in this case by untruthfully answer DNS Queries to example.com with its own IP address. As soon as this was done, Arturo and I talked about wrapping a nice CLI around it and came up with a plan, which i will explain briefly. basically, there are two core components to EvilGenius: - Censorship providers and - Measuremet Instruments. Both of those components are boxes that run in different configurations described by a .yml file. Our first goal is to generate vagrantfiles from those files and boot them up. During the weekend, I'm trying to tackle the Censorship provider class and see how it goes from there. You all have nice and relaxing weekends Johannes

1 0