<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=iso-8859-15">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
<br>
Hello everyone,<br>
<br>
I'm the one behind the Onion Name System (OnioNS), a Tor-powered
distributed DNS for Tor hidden services. It's been several weeks
since my project was selected for the SoP program, and I've finally
got around to posting here about it. My project aims to solve the
major usability issue that has been with hidden services from the
beginning: their un-memorable addresses. I'd like to discuss a bit
about how it works, where my project is described, and where I am
with the implementation.<br>
<br>
Under OnioNS, a hidden service operator can anonymously claim a
meaningful domain name for their hidden service (a map between the
.tor and .onion pseudo-TLDs) and then transmit it over a Tor circuit
to an OnioNS server, which is also a Tor router. The claim
propagates across the Tor network. Later, a user may type a .tor
domain name into the Tor Browser. My software intercepts this
domain, performs a lookup over a Tor circuit to an OnioNS node, and
learns the corresponding .onion address. Then it tells the Tor
client this, which contacts the HS in the normal way. The result of
this process is that a hidden service loads transparently in the Tor
browser under a meaningful name.<br>
<br>
I introduce several data structures, but the most important one is
the Pagechain, a distributed structure of linked Pages. Pages
contain Records, Records contain .tor -> onion associations.
Anyone who is familiar with blockchains will recognize the behavior
and application of this structure immediately. However, here the
head of the Pagechain is not managed by miners, but rather by a
short-lived subset of Tor nodes called a Quorum. They receive
Records and merge them into the Pagechain. At the moment I've
decided to use 127 Quorum members and rotate them every week. They
are randomly selected, but the process is deterministic; I am using
the cached-certs + cached-microdesc-consensus documents, which
everyone has, to seed a PRNG that then derives the Quorum. Clients
don't need a copy of the Pagechain to use the DNS, but rather they
can just rely on their existing trust of the Tor network (including
the Quorum and name servers) and verify their signatures on data
structures. Also unlike a blockchain, my Pagechain has a finite
length: the oldest Page will eventually drop off, which forces
domains to be renewed periodically. I have also introduced
mechanisms that 1) allows clients to authenticate the domain name to
the hidden service, 2) allow clients to authenticate a
denial-of-existence claim from a name server, and 3) prevent name
servers from forging .tor -> .onion associations. These
vulnerabilities are still generally open on the Internet DNS. I have
also tried to minimize networking costs, since Tor circuits are
slow.<br>
<br>
To reduce CPU and network requirements, I want Tor routers to have
Ed25519 keys. Let this project add additional pressure on that item
on the to-do list.<br>
<br>
Recommended readings:<br>
<a class="moz-txt-link-freetext" href="http://onions55e7yam27n.onion">http://onions55e7yam27n.onion</a> -- the official hidden service for
this project, but a work in progress.<br>
<a class="moz-txt-link-freetext" href="https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf">https://github.com/Jesse-V/Thesis/blob/master/conference/acm-ccs.pdf</a>
-- the ACM paper pending peer review<br>
I no longer recommending reading my original thesis, please use the
above links instead.<br>
<br>
My prototype can be found here: <a class="moz-txt-link-freetext" href="https://github.com/Jesse-V/OnioNS">https://github.com/Jesse-V/OnioNS</a>
It's a bit unstable, but it does work once and sometimes twice.
Please contact me (kernelcorn on IRC) before running the prototype,
I need to ensure that the name server is up before you can try it
out. You can also send me registrations over IRC and I can add them
in.<br>
<br>
I am asking for help with the client-side functionality. I'm
currently doing the *.tor interception and lookup resume in
connection_edge.c but the software frequently crashes with this
approach, (I've learned why) and I'd like to migrate it to Stem for
now. I need to intercept .tor domains, pause the lookup (letting the
Tor Browser spin), send the hostname over a named pipe or TCP
socket, read back a .onion address, then tell Tor to resume the
lookup under the .onion address. This way, the HS loads under a .tor
domain. All other lookups should load as normal. I've never used
Stem before but I understand using it will be a lot easier than
hacking Tor. I have Stem up and running now. Any recommendations for
what I'm trying to do here?<br>
<br>
- --<br>
Jesse V. (kernelcorn)<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1<br>
Comment: Using GnuPG with Thunderbird - <a class="moz-txt-link-freetext" href="http://www.enigmail.net/">http://www.enigmail.net/</a><br>
<br>
iQEcBAEBCAAGBQJVWnpiAAoJEK2XNk/CC+yA0MsH/Ahg3V1U+bIRqawmVu5Ju85C<br>
gAqVqJx3pYsJPDHpmZU2OGICGIAWVMS0d8wA39H42MBJG3AP/1PGevlB8tK+/i5K<br>
t/o3vLTt9WpuxL3Lf2+VihlDTFnUSQz+02pMyghwjS3ANoutoLb2wMB/EeSn74FS<br>
ozLjEkO7fbyEx1Qzp4xDHKNjfRBmkn2k83O9YhEPZ6d6VYFHrCfsygd6XvHpuPzT<br>
XLu3OyamFeT5BjZgkX2gge+zG9UUOmDLC2aCQa83gHxcty3Sdh5aZ33oVfx9bROU<br>
+AaD2yAbLNaq/mEmp2qaAOnsQCzBTrRJ5CX9jyLvCOVYi3SZtl/4Ju/oomWqHl0=<br>
=TvQm<br>
-----END PGP SIGNATURE-----<br>
<br>
</body>
</html>