tor-dev February 2015

tor-dev@lists.torproject.org

60 participants
52 discussions

Re: [tor-dev] [tor-assistants] Researching Tor for Master's Thesis
by Florian Rüchel 18 Feb '15

18 Feb '15

Hi everyone, I am attaching the conversation from the assistants list over. Here is the TL;DR: I want to write my master's thesis on Tor, preferrably on a topic that has to do with Hidden Services and/or Cryptography in Tor. I have followed George's recommendations and read through some of the sources provided. In the end, several topics seem appealing to me, but before moving on I'd like to get some feedback from you guys on whether you'd consider the topics worth researching or even have some additional ideas. HSDir tracking: I have taken a look at the idea of PIR ( https://en.wikipedia.org/wiki/Private_information_retrieval) and the problem associated with getting HS descriptiors. I have only looked at the theory of PIR so far and not yet an idea of how this can be accomplished (and to what extend) in practice. Certificates for HS: I find this topic particularly interesting and have followed the discussion. The general concept seems like a great thing to achieve and it could actually outperform the regular SSL/CA infrastructure stuff as it could remove the need for CAs. Unfortunately, this seems something that is not extensive enough to warrant a whole thesis. If you guys think otherwise, please let me know. Tor with mix features: Tor has the explicit goal of being a low-latency network. However, there are several protocols where high-latency would be acceptable. I liked the idea of high latency HSes (https://lists.torproject.org/pipermail/tor-dev/2014-November/007818.html). I'd like to know what you think about this idea being viable. It would have the advantage of being very flexible from just a theoretic evaluation down to a real implementation so I could adjust this to my time. But only if this is actually desired so it does not need to stay theoretic. I think it would be very interesting to evaluate whether this can improve or hurt anonymity of low-latency users, as well. Traffic confirmation attacks: This is here more or less for completeness. I know this topic is open for several years and would be one of the most powerful countermeasures to deploy but unless someone has started on something that I could build upon, I don't see myself coming up with something useful here. Guard discovery attacks: I have only read roughly what these attacks are. I'd like to know if it would make sense to take a deeper look here, i.e. you think extensive research is needed on that topic. Improving crypto for HSes: The blog entry on HS (https://blog.torproject.org/blog/hidden-services-need-some-love) vaguely states that crypto for HSes could be improved. However, the article is over a year old and I know the new rend-spec-ng exists, so I'd like to know whether there's anything here to work on. I have a fairly good background on cryptography, so I'd like to help here if help is needed. Cryptography: There's two proposal ideas, one from 2010 (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-cr…) and one from 2011 (https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/ideas/xxx-ne…) which builds on that. Has some of this been addressed? Is this still being worked on or just leftover that has already been integrated to the desired level? Would an analysis of the cryptography used in Tor make sense to you, i.e. building on those documents reviewing where and how Tor uses cryptography to secure its operations and evaluating the methods used? Onion addresses: I took a look at several approaches around censorship-resistant lookups, e.g. the GNS (see George's recommendation below) and Aarown Swartz's proposal on squaring Zooko's triangle by achieving all three properties. I think it would be a cool thing if it were actually possible to improve onion addresses to be human-readable, especially when they get longer by using bigger keys in the future (since 80 bit won't suffice). I don't know if this is actually possible (I see some issues on Aaron's proposal and Dan Kaminsky confirmed them) but working out a scheme that makes handling the names easier for users while not sacrificing the security would help a lot, I think. This would be the bigger topics I have found on which I could see myself building a thesis. I also stumbled upon smaller research questions (e.g. whether running a bridge/relay is good, bad or doesn't make a difference for anonymity) but none of those warrant a full 6 month thesis so I discarded them for the moment. If you could take the time to evaluate my ideas and let me know what you think, I'd greatly appreciate that. The hardest thing here as an outsider is to assess the current situation and figure out where work is actually needed and where problems/issues have already been addressed so any help from you guys would really help me. Thanks in advance & Regards, Florian Rüchel P.S.: George: > I'm about to relocate, so my reply will be short! Come and find us in > CCC for more. Unfortuantely, I don't know what you mean by CCC :( > Ah, I'm also a fan of the FluxFingers team :) Great! Have played some CTFs for yourselves, then? Are you member of a team? Thanks for your quick reply, it has helped me a great deal moving forward on this project. On 12.11.2014 23:15, George Kadianakis wrote: > Florian Rüchel <florian.ruechel.tor(a)inexplicity.de> writes: > >> Hello everyone, >> >> I am about to write my master's thesis and am evaluating Tor as my >> research topic. I have read through several documents (including the >> Ideas page of the research page and the Research page on the Volunteer's >> page). I also read "Hidden Services need some love" >> (https://blog.torproject.org/blog/hidden-services-need-some-love) and >> especially followed the section on cryptography (reading both proposals) >> with great interest. >> >> Before diving into more of those documents that are available, I noticed >> you encourage people to contact you through this list should they wish >> to conduct research. Right now I am in a very early state as I have not >> chosen a topic yet. In my choice I want to do something that benefits >> the Tor network, satisfies my professor and involves topics I generally >> care for. >> >> As noted above, I took particular interest in Hidden Services and >> general cryptography used by Tor. So if possible, I would like to have >> those two (or one of those topics) to focus my thesis on. Of course, I >> need to define my topic in such a way that it fits my time schedule >> (half a year, full-time) and that my professor accepts it. >> >> Now, before moving any further I'd like to know if there are any further >> documents I should read that are more up to date than the documents >> indicated above (especially the crypto specs are from 2010/2011 so I >> don't know how far the network has moved here). It would also be >> interesting to know whether some of the issues described for Hidden >> Services are already addressed and whether my research would be better >> directed somewhere else. >> >> I would be glad if you could take the time to respond to my request so >> as to help me define my topic better. >> > Greetings, > > I'm about to relocate, so my reply will be short! Come and find us in > CCC for more. > > I'd first suggest you to join and skim over the [tor-dev] mailing list: > https://lists.torproject.org/pipermail/tor-dev/ > Especially this month there has been an increase of threads about > hidden services, so I'd suggest you to check it out. > > I'd also suggest you to read the recent blog post about the attacks > against HSes: > https://blog.torproject.org/blog/thoughts-and-concerns-about-operation-onym… > > The blog post offers plenty of material for research, since it lists > various attacks and issues with the security of HSes that we need to > fix and would definitely benefit from further thinking. Check the > guard discovery [tor-dev] thread for example. > > Also check this recent thread: > https://lists.torproject.org/pipermail/tor-dev/2014-October/007642.html > which is part of figuring out work for a funded project. Most of those > tasks are not very interesting for you, but you can find deeper > research questions in some of them. > > Another guy recently did his thesis on HS scaling: > https://lists.torproject.org/pipermail/tor-dev/2014-April/006788.html > > There is also this stuff: > https://lists.torproject.org/pipermail/tor-dev/2013-November/005878.html > related to the HSDir hashring in rend-spec-ng.txt. > > And check out the "Trawling Hidden Services" paper by Ralf et al. > > For example, on a more key management tone, petname systems for HSes > would be very interesting, which is related to the recent work of > GNUNet with GNS: > https://gnunet.org/gns > > BTW, keep in mind that some of these projects will be moving during > the next year. > > Also, if you have public questions which would benefit more people, it > would be great if you could post in [tor-dev] instead of here. It's > good to answer obscure HS questions in public so that more people can > understand the protocol. > > Ah, I'm also a fan of the FluxFingers team :) > > Thanks for the interest and hope this was useful.

7 9

Release: obfs4proxy-0.0.4
by Yawning Angel 17 Feb '15

17 Feb '15

Hello all, I just tagged obfs4proxy-0.0.4, though the changes do not affect most people directly, I figured it's worth an announcement. Changes in version 0.0.4 - 2015-02-17 - Improve the runtime performance of the obfs4 handshake tests. - Changed the go.crypto import path to the new location (golang.org/x/crypto). - Added client only support for ScrambleSuit. This is more useful for the Tor Browser people than anyone else since it means that the next build can remove the old go.crypto cruft from the build process, and the ScrambleSuit client provider can be switched over to obfs4proxy like obfs2 and obfs3 have been. With Go PTs being phased into Orbot as well, this release should allow for a smooth transition from obfsclient to obfs4proxy. A note about the build time dependency change, for packagers: What: code.google.com/p/go.crypto -> golang.org/x/crypto Why: The Go developers decided to move the repository, and Go libraries are referred to in the code via import location. The source in the code.google.com repo was also updated to mirror the new repository, so internal dependencies all reference the new location. Workarounds: If changing the build time dependency is not an option, you have an existing go.crypto package that will not change, and you are building with Go < 1.4, revert: cdeda5724124ca393c87be6d01c84fe4f906d612 Old copies of go.crypto will not compile with newer versions of the Go compiler so packaging golang.org/x/crypto is advised in the medium to long term. Questions, comments, feedback appreciated, -- Yawning Angel

1 0

Static compile config and incore runtime [HS via Control Port]
by grarpamp 17 Feb '15

17 Feb '15

In situations where it is inconvenient / impossible to manage / rely a bunch of library files, dropping a static compiled tor in place is handy. Similarly, it should be possible to completely configure and run tor in that one static binary and in ram... no other files at all (torrc, geoip, .tor state dir, etc)... depending on your config. It may be necessary to compile in a basic torrc just to get tor going, before you can spawn a control port. Other torrc/commandline options may not as of today be available via the control port... so they would need compiled in and just run './tor' . In some unique situations you may not even be able to spawn/access the control port. So ability compiling in HS keys etc would be useful there. There may already be some tickets for these things.

2 1

Tor Project Idea | GSOC 2015 | Panopticlick | fake fingerprint
by Rohit Dua 15 Feb '15

15 Feb '15

Hello I'm Rohit from India, aspiring for gsoc-2015(TOR). This will be my 2nd consecutive year for gsoc participation. Previous mediawiki. Project:BUB tool <http://tools.wmflabs.org/bub/> I stumbled across Panopticlick related project <https://www.torproject.org/getinvolved/volunteer.html.en#Panopticlick> in tor project ideas. I would like to propose a project relating to this. Panopticlick obtains browser fingerprints mainly via javascript objects(navigator, screen, window etc.) These objects are easy to fake in webkit browsers, without touching the underlying source code of browsers, eg. using *__defineGetter__() *after every* javascriptObjectCleared.* If we could compile a large dataset of possible values of js object for several popular browsers, we could use that to randomize the fingerprint for each network request. The dataset could also contain random http header values etc. I am building a python library that does somewhat similar. https://github.com/rohit-dua/selkie (*in development*) It uses pyqt for headless browsing/scraping of webpages. It is a python library that mimics different browser fingerprints by faking(randomizing) the values of navigator, screen object, headers etc. I also intend to add biometric library that mimics humans mouse movements/ keypress statistics for clicking links and surfing pages. I propose to build a similar headless bot that mimics several browsers fingerprints and could be used for anonymous scraping of data and/or adding a feature of random fingerprint in awesome tor tools. Also to improve anonymity location based datasets could be provided(*supported in the above library*) as extra/feature.(maybe downloaded from statcounter.com) Thanks Rohit Dua IRC:rohit-dua github: rohit-dua <https://github.com/rohit-dua/> (8ohit.dua(a)gmail.com)

5 6

Fwd: Orbot v15-alpha-3 with VPN and Meek!
by Nathan Freitas 14 Feb '15

14 Feb '15

----- Original message ----- From: Nathan of Guardian <nathan(a)guardianproject.info> To: guardian-dev(a)lists.mayfirst.org Subject: Orbot v15-alpha-3 with VPN and Meek! Date: Sat, 14 Feb 2015 02:57:34 -0500 More progress on Orbot VPN support, and now, thanks to our new PLUTO library (https://github.com/guardianproject/pluto), support for Meek (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 as well. Currently you can use Meek or you can use VPN, but you can't use both together... still working on that, as I can't get Meek to talk to the passthrough HTTP proxy I use to allow socket connections out of the VPN filter. To use Meek, just enable the "Bridges" button on the home screen, without using any bridge config info, and it will default to using the Meek Azure instance. If you set the bridge line to 0 it will use Google, and 1 it will use Amazon, and 2 it will use Azure. The VPN mode is just as easy, just enable VPN using the homescreen toggle button, then start/restart Orbot. All apps on your phone should now be running through Tor. Remember, Bridges and VPN don't work at the same time, for now... but please test both features separately, and let me know how well they work for you. APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or https://github.com/n8fr8/orbot/tree/v15-dev -- Nathan of Guardian nathan(a)guardianproject.info

4 4

Re: [tor-dev] Fwd: Orbot v15-alpha-3 with VPN and Meek!
by Nathan Freitas 14 Feb '15

14 Feb '15

On Sat, Feb 14, 2015, at 03:04 AM, CJ wrote: > > > On 14/02/15 08:58, Nathan Freitas wrote: > > > > > > ----- Original message ----- > > From: Nathan of Guardian <nathan(a)guardianproject.info> > > To: guardian-dev(a)lists.mayfirst.org > > Subject: Orbot v15-alpha-3 with VPN and Meek! > > Date: Sat, 14 Feb 2015 02:57:34 -0500 > > > > > > More progress on Orbot VPN support, and now, thanks to our new PLUTO > > library (https://github.com/guardianproject/pluto), support for Meek > > (https://trac.torproject.org/projects/tor/wiki/doc/meek) and soon Obfs4 > > as well. > > > > Currently you can use Meek or you can use VPN, but you can't use both > > together... still working on that, as I can't get Meek to talk to the > > passthrough HTTP proxy I use to allow socket connections out of the VPN > > filter. > > > > To use Meek, just enable the "Bridges" button on the home screen, > > without using any bridge config info, and it will default to using the > > Meek Azure instance. If you set the bridge line to 0 it will use Google, > > and 1 it will use Amazon, and 2 it will use Azure. > > > > The VPN mode is just as easy, just enable VPN using the homescreen > > toggle button, then start/restart Orbot. All apps on your phone should > > now be running through Tor. > > > > Remember, Bridges and VPN don't work at the same time, for now... but > > please test both features separately, and let me know how well they work > > for you. > > > > APK: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk > > SIG: https://guardianproject.info/releases/Orbot-v15.0.0-ALPHA-3.apk.asc > > > > Source: https://gitweb.torproject.org/n8fr8/orbot.git/log/?h=v15-dev or > > https://github.com/n8fr8/orbot/tree/v15-dev > > > Hello Nathan! > > Glad seeing this VPN part going further! I just have concerns regarding > my app compatibility (orwall): does orbot still opens ports on > localhost, and are they still the same, or shall I detect orbot version > and/or probe for opened ports? Everything is the same as usual. I don't think we can support both Orwall and VPN at the same time, so that will be another choice the user will have to make. The VPN doesn't fulfill the requirements of advanced users who want the level of protection provided by Orwall and what Mike Perry originally outlined. It is tricky to start on boot, there is no guarantee system services can't route around it, and it can be killed if Orbot crashes. Root and IPTables will still be required for that. VPN mode is really just for circumvention of app blocks by novice users. +n

1 0

Re: [tor-dev] RFC: Ephemeral Hidden Services via the Control Port
by Nathan Freitas 14 Feb '15

14 Feb '15

On Fri, Feb 13, 2015, at 07:45 PM, Yawning Angel wrote: > Yes, this means that if you run "kittensomgmewmew.onion" and are scared > of the NSA's persistent attempts to extract your hidden service key, > via ultrasonic laser beamed from their satellites, you could run your > tor instance entirely in a ram disk, and load the HS key manually each > time from a USB token you wear around your neck. A very practical use of this in the Orbot context, is that we can now store all HS identity data in an IOCipher encrypted volume, which the user can unlock with a strong passphrase when they want to start up their onionsites. Currently, all HS data is stored in the standard Tor data paths, only protected by the per-app user permissions on Android. This means the data can be accessed by rootkit capable malware apps and forensic extraction tools. With IOCipher, that would make that a great deal harder, and impossible if they were in a locked state (i.e. the key is not in memory). We are working on adding OnionShare-capabilities to Orbot, so this is well timed! +n

1 0

Authority Directory new IP
by SiNA Rabbani 13 Feb '15

13 Feb '15

Dear Tor, I am planning to change the IP address of Faravahar, it's basically a reconfiguration of the networking and how we are hosting it, to better stand future DDoS attacks. Here is the ticket for it: https://trac.torproject.org/projects/tor/ticket/14487 Should I also attach a patch for tor's source code? All the best, Sina "Be the change that you wish to see in the world." - Mahatma Gandhi

1 0

Multithreaded Crypto
by Nik 12 Feb '15

12 Feb '15

Hello, I'd like to try to help out and do some work on Tor's multithreaded crypto, specifically for incoming/outgoing cells. I've read through https://trac.torproject.org/projects/tor/wiki/org/projects/Tor/Multithreade… as well as #1749 and #7572. I have a few questions for tor devs and people who've worked on/are working on the relevant bits of code: 1) Does the section "Phase 1: Cell crypto" in the Multithreaded crypto wiki page still reflect the current design and coding plans (along with the additions from the "Athena's notes" section)? 2) If so, approximately what stage of "Cell crypto: The plan" (on Multithreaded crypto wiki page) has development gotten to/is work currently being done on? I (briefly) looked around in master, and it looks like a crypting queue isn't being used yet. So if this is still the plan I guess I can assume that development is somewhere in phase 1? 3) Is there any other work/other branches I should take a look at? (i.e. in #7572, nickm commented "Andrea made some progress here", and I'm vaguely aware that there was a GSOC project last summer on multithreaded crypto, but it's not clear to me how far that effort got or how much of that code has made it into master.) 4) Is anyone currently working on this I should talk to? I know this can be a tricky thing to get right, so I just want to get a sense of where the best place to start might be and also avoid duplicating work someone else is doing/has already done. Thanks! All the best, Nik

1 0

Re: [tor-dev] A proposal to change hidden service terminology
by str4d 11 Feb '15

11 Feb '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Erik de Castro Lopo wrote: > A. Johnson wrote: > >> Several of us [0] working on hidden services have been talking >> about adopting better terminology. > > In general, I am in agreement with this, but I wonder if now might > be a good time to unify Tor terminology with other similar > technologies like I2P and Cjdns/Hyperboria. It is interesting that you raise this, because we at I2P have been thinking the same thing. We discussed the issue of I2P terminology at 31C3 and decided that after 12 years of Tor/I2P coexistence, Tor had the upper hand with regard to commonplace terminology. In our next release, we are changing most of our user-visible tunnel-related terms (I2P destination, tunnel, eepsite etc.) to instead use "Hidden services" in some way [0], to draw parallels to Tor hidden services - because as far as an end user is concerned, they do "pretty much" the same thing. And as far as we could tell, "hidden services" is now considered "too generic" for Tor [1], so it made sense to use it generically. Tags are now frozen for the 0.9.18 release, but we are still open to further discussion about terminology. > > I have heard someone (forget who) propose that 'Dark Web' be > dropped in favour of CipherSpace which could include all of these > privacy perserving protocols, leaving terms like "OnionSpace" for > Tor, "I2PSpace/EEPSpace" for I2P etc. I am certainly in favor of this kind of collaborative approach. It's hard enough already trying to make this stuff understandable to end users (usability and UX of the tools themselves aside), without having multiple kinda-similar-but-not tools trying to do so in different ways. A "united concept front" would benefit tools _and_ users. str4d [0] http://zzz.i2p/topics/1780-hidden-services-done-right [1] http://www.dailydot.com/technology/tor-crowdfunding-hidden-services/ > > Cheers, Erik > -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJU20J5AAoJEIA97kkaNHPnnzYQAI1iVeLcOcjVCR/hJ4nYq8ND DlyfENy0QYUtg9k85qIqoA2EEskUPDHDSRMqLZciQo2RgC7nFoNmgNjePUKXNtGA hLDodOjuEUcXQyA0+fl3v6sfzLxOc+E6sbLdnuV/wDgTuSPveVOgWi5eGUX2mb0/ DbYgMxp0kD0KghFPF1EPtj0S6sP1J/wwoFMJDhYm3no7qbWK1CqQvtfyxjkSXAmg EcdVWOqOUjA66ETNaMpQQVTiZ5MZVKM+2u5bDFDpwd4cEOuoy5bkiwy5gZLsIRot hB13as06kiWz6WAN8gsPqHF7t0JslHh9jSKIYRwuBf+e/NUtCGjGVVGf4YHwolgB 2AjuoeTAxzzBeNB6BvmSNw5h/oBt2S1fg0/QirCDrmpuQDKomD8+NI5EFatAiNkn 5RsbPrN/Clp+fJeW/Ypgh+ZUT2pO+Kps9fkgAs4u5QI6FnuCPvYGjsTil5a599KA 81FKzXOHNJ9L7IORmPymOZbN/Ba+upu6cznuB5KCRAt9q5QxAonx9Ry/oulC9kkF 9gacUY7Krglg5AUUlZA9dCesUftP8yeGhM52RreAkJTfK/rI94WK9YIaV/C3lbPb 233SthcQK3SoyRqR49B1ht3/4DgVah+6/K9TfQN7ZHjA0LizqUILqWuqO/5CLxNX uqkIyMePKodbzO8qr2TW =GTFn -----END PGP SIGNATURE-----

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

tor-dev February 2015