[tor-dev] prop224: Ditching key blinding for shorter onion addresses
burdges at gnunet.org
Tue Sep 27 15:15:26 UTC 2016
I'll add a note on GNS to your wiki George, but..
On Sat, 2016-08-20 at 16:48 +0300, George Kadianakis wrote:
> We really need to start serious work in this area ASAP! Maybe let's
> start by
> making a wiki page that lists the various potential solutions (GNS,
> Blockstack, OnioNS, etc.)?
There were a couple reasons I stopped the work on integrating
GNS with Tor, which Christian asked me to do : First, I did not like
that users could confirm that a particular subdomain exists if they know
the base domain's public key. Second, I disliked the absence of the
collaborative random number generator protections you guys added to Tor.
Now my first concern is not an issue in the context of a "name system"
for servers, well it's clearly desirable there. It's just not desirable
if you start talking about using the name system for more social
applications, which people do for GNS.
Also, my second concern is not an issue if you envision the system being
backed only by Tor HS record, not GNS records. In that scenario, the
cost you pay is (1) you need a forwarding record for Tor HSs, and (2)
sites with subdomains need to continually reupload those them as the
collaborative random number changes.
This does not give you global names obviously, but it does give you GNS
style non-global names in the threat model desired by the 224 or
whatever. In effect, you'd use the existing HSDirs for non-global name
links, instead of some new PIR scheme like U+039B and others proposed.
Now non-global names are not necessarily useful unless people can
socially construct naming hierarchies around them, but that's doable.
And they can refer to each other. etc.
Anyways, I think adding forwarding records and the signing key
derivation trick from GNS to Tor might give the Tor project a way to let
different naming schemes develop organically. And not be overly
responsible for issues arising from Zooko's triangle.
tl;dr I'm not saying GNS itself is the way to go, but GNS's subdomoman
crypto trick along with Tor's existing HSDir structure might improve
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the tor-dev