The annual Privacy Enhancing Technologies Symposium (PETS) 2017 is a privacy nerd’s dream and has always been on my list to attend. Unfortunately, I did not make it out to Minnesota to attend but all the papers are readily available online so yay, open access!
These are my notes about some interesting research presented this year based on the papers that were released and the live tweets that Nick Mathewson was doing during the event.
A Wide-Area Testbed for Tor
This was presented by some of the people from the Tor Project along with researchers from the Navy. (Reminded me that Tor Project folks still have friends in the Navy. Let the conspiracy theories continue. :P)
I’ve personally heard a lot of people want to do something like this research topic – basically, I want to run a tor network that doesn’t affect the Tor Network. In fact, I believe that RIT was making efforts to do this and as I look at the authors, guess who’s listed as an author. I’ve done experiments in this direction using Docker Swarm but this paper is talking about taking it to the next level.
The goal here is to setup a test environment that parities the Tor Network so you can run large scale experiments without affecting real-world tor clients. Some of the benefits:
- Practical traffic analysis
- Impact on attacks such as RAPTOR
- Testing fault tolerance
- Testing Performance
Right now it’s just gaging interest but I think if it’s funded, it could push anonymity research exponentially. I just question how open it will be. I’d love to volunteer for something like this.
The Onion Name system
Tor’s onion services are going to be headed for some major changes soon.
One of them being bumping up their hashes from SHA1 to SHA256 which means that
instead of onion addresses like
facebookcorewwwi.onion
You’re going to get hostnames like odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion
that are 54 characters long. You can read more about the situation here.
The idea can be simply summarized as an anonymous DNS-like system but the design problems are very complicated. The paper defines the goals as:
- Allow anonymous registration for .tor domain names
- (Continue to) Allow anonymous domain lookups
- Cryptographic guarantees on the authenticity of the domain
- Provide unique domain names
- Be decentalized to reduce risk of a single point of failure that would have catastrophic results
- Be fast, lightweight, and extensible
On first read it seemed like an over-engineered solution but looking at the challenges it’s trying to solve, it makes a lot of sense. There are a lot of moving parts to summarize but let me highlight a few interesting aspects.
The architecture has three parts: OnioNS-client to be run with the tor client software, OnioNS-server running a micro HTTP server, and OnioNS-HS for the onion/hidden service it’s hosted on.
You can run your own OnioNS server and claim a domain name on top of the .tor
TLD. So I could run antitree.tor and provide subhost registrations for hosts like
mywebservice.antitree.tor.
The system uses Bitcoin Beacon as a seed of verifiable randomness. I get the feeling that it would eventually move away from relying on the Bitcoin Network for that and instead use the new Tor Shared Randomness feature they’ve recently added since it’s similar and stays in-band.
Unlike NameCoin
which has a similar design, there’s a defense against domain
squatters so that it’s not first-come-first-serve. As I understand it (high
risk of being wrong here), a person can register for a host by performing a
proof-of-work calculation that generates a ticket. A ticket is sent to OnioNS
and Quorum nodes (ala the blockchain) who determine a subset of registrants
that “have won the lottery” based (partially) on how much effort the registrant put in to
make the ticket. In the end a record is created that will
point mywebservice.antitree.tor to
odmmeotgcfx65l5hn6ejkaruvai222vs7o7tmtllszqk5xbysolfdd.onion and this is
served by OnioNS mirrors distributed around the network and authentication
is performed by putting a root domain signature into the consensus document.
It’s crazy enough to work but it still sounds to me that you’re making a lot of 6 hop circuits during communications. When a browser connects to a .tor domain, it will lookup the service location and establish an introduction point. The client will then route through 3 hops and the service will also route through 3 meaning every “lookup” over OnioNS is done this way. After that, the corresponding .onion domain is returned and has to do that same 6+ hop circuit – so every request ends up being at least 12 hops. I believe there’s even more overhead than that but that alone is going to be a pretty intense usability problem for onion services.
There are some alteriatives to this but this does seem like the most popular option out of all of the options thus far.