[tor-dev] prop224: Ditching key blinding for shorter onion addresses

[Jeff Burdges]

On Wed, 2016-09-28 at 19:45 -0400, Jesse V wrote:
> I am curious, what is your issue with the subdomains? Are you
> referring to enumerating all subdomains, or simply being able
> to confirm that a particular subdomain exists? 

Yes, confirmation of subdomans can become a problem in some contexts
where GNS gets discussed as a possible solution.  

If I know that blabla.onion exists as a website, then it's good that I
can learn that www.blabla.onion exists as a website.  

If otoh I know that blabla.zkey is a GNS record representing a Bob's
contact list, then it's bad that I can learn that alice.blabla.zkey
exists.  

Jeff

p.s.  In my message, I suggested roughly :  Let P = p G be a elliptic
curve point so that P.onion is a hidden service with abbreviated URL x.
If y is a domain name element string, then y.P.onion and y.x point to
Q.onion where Q = H(s,P) * P for some hash function H mapping into the
scalars.  And q = H(s,P) p is the private key for that HS record.  Now
this Q.onion HS record could simply forward users to another HS record
with a private key not controlled by p.  This means the owner of x & p
can make the HSDirs forward requests in a verifiable way.  The downside
is more HS records.  This could help create a diversity of naming
solutions whose TLDs (x above) are controlled by different authorities.
It's not helpful if you want x to be controlled in some distributed way
though.  In fact, I suppose most Tor name service proposals would be
distributed, giving my idea only very limited usefulness. 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20160929/b3f25dcc/attachment.sig>