[tor-dev] A modest proposal for a petname system in ideas/xxx-onion-nyms.txt

[William Waites]

On Fri, 16 Dec 2011 17:14:52 -0800, jacob at appelbaum.net (Jacob Appelbaum) said:

    ioerror>  Beppe wishes to register "antani" to point to
    ioerror> v2cbb2l4lsnpio4q.onion so he creates a a TCP service
    ioerror> listening on his .onion will respond with the string "reg
    ioerror> antani" when interrogated.

Ok, so far so good.

    ioerror> 3.2 Tor2web implementation

    ioerror>   Beppe creates a file called "onion.txt" containing the
    ioerror> string "reg antani" and uploads it to the root of his web
    ioerror> server. When User visits v2cbb2l4lsnpio4q.tor2web.org the
    ioerror> t2w checks if his database contains a mapping with
    ioerror> v2cbb2l4lsnpio4q.onion, if it does not, it requests the
    ioerror> http://v2cbb2l4lsnpio4q.onion/onion.txt file.

This would appear to either introduce a single point of failure, the
tor2web service, or a race condition leading to differing mappings if
there is more than one such service.

What if instead, we used a similar mechanism as we already have for
the hidden services and do say hash("antani").nym and push that out to
the introduction hosts. The introduction hosts would check if they can
resolve it, if they can, the request is rejected, if they cannot then
they keep the mapping (careful implementation to avoid race conditions
here). Have an cache+expiry mechanism from there so the mapping isn't
trivially lost when the hidden host goes offline.

The requester just computes hash("antani").nym and goes to find that
hidden service in the normal way.

The only difference from the existing hidden service is that in this
case the secret behind the hash, "antani" is publicised.

An added benefit is that only the requestor and the operator of the
hidden service can know the nym a priori, the introduction servers
don't know what nyms they are providing introductions for.

Does this make any sense?

Cheers,
-w
--
	       William Waites <wwaites at tardis.ed.ac.uk>
 Visiting Researcher, Laboratory for Foundations of Computer Science
	    School of Informatics, University of Edinburgh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20120102/e71af8ef/attachment.pgp>