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@tardis.ed.ac.uk Visiting Researcher, Laboratory for Foundations of Computer Science School of Informatics, University of Edinburgh