Home » Featured » Hackfest Speeds Up Development for Next Generation Onion Services
Click Here To Hide Tor

Hackfest Speeds Up Development for Next Generation Onion Services

A blog post on the Tor site said that a couple of weeks ago, Tor dev.’s got together and worked on nothing but onion services for an entire 7 days.

“The event was very rewarding and we wrote this blog post to share with you how we spent our week!” the post read.

This is Tor’s second ‘onion hackfest’. The last being legendary Arlington Accords in July of 2015. Tor has been working on Proposal 224; or, Next Generation Onion Services for the past couple months and this week long meeting was to help get them ahead with the developments.

“It is extremely helpful to meet and work together in the same physical area as we hammer out open issues, review each other’s code, and quickly make development decisions that would take days to coordinate through mailing lists. During hackfest we did tons of work. Here is an incomplete list of the things we did:

In our previous hidden service hackfest, we started designing a system for distributed random number generation on the Tor network. A “distributed random number generator “is a system where multiple computers collaborate and generate a single random number in a way that nobody could have predicted in advance (not even themselves). Such a system will be used by next generation onion services to inject unpredictability into the system and enhance their security.

Tor developers finished implementing the protocol several months ago, and since then we’ve been reviewing, auditing, and testing the code.

As far as we know, a distributed random generation system like this has never been deployed before on the Internet. It’s a complex system with multiple protocol phases that involves many computers working together in perfect synergy. To give you an idea of the complexity, here are the hackfest notes of a developer suggesting a design improvement to the system,” The anonymous Tor developer wrote.


Onion service developers have tested this system, by creating fake small virtual Tor networks on their own laptops and testing it to insure it works. It was agreed however, that the basic tests are not enough to properly examine an advanced network like this.

“To really test something like this we need to make a Tor network that works exactly like the real Tor network. It should be a real distributed network over the Internet, and not a virtual thing that lives on a single laptop,” the dev wrote.

That’s what the Montreal hackfest was intended for. Each dev opened up themselves a Tor node, enabled ‘distributed random number generation’ and had Tor nodes all over the globe. They had made a private network, just for themselves. It allowed them to test 11 separate Tor nodes that were all performing the random number generation protocol for seven days.

“This allowed us to test scenarios that could make the protocol burp and fail in unpredictable ways. For example, we instructed our testing Tor nodes to abort at crucial protocol moments, and come back in the worst times possible, just to stress the system. We had our nodes run ancient versions of Tor perform random chaotic behaviors, disappear and never come back, etc.,” the Tor developer goes on.

All this helped them find bugs and edge cases. It also confirmed that the system can make it through a network failure that actually does happen on the internet. Tor plans on keeping the testing network live and urges more people to help with it.

According to the post, they also working on improving the design of next generation onion services by improving the clarity of the specification of proposal 224 and fixed its inconsistencies and errors in the text. They also designed improvements to the onion service descriptor download logic of proposal 224 and ways to improve the shared randomness protocol in the future.

“We discussed ways to improve the user experience of the 55-character-long onion addresses for next generation onion services (compared to the 16-character-long onion addresses used currently). While no concrete design has been specified yet, we identified the need for a checksum and version field on them. We also discussed modifications to the Tor Browser Bundle that could improve the user experience of long onion addresses,” the post said.

Tor plans to keep the current onion service system for now. When the proposal is launched, they will be able to handle both onion services, current and next generation.

One comment

  1. Thank you kids :::)



Leave a Reply

Your email address will not be published. Required fields are marked *


Captcha: *