[tahoe-dev] tor services as caps (was Re: switching from introducers to gossip?)

[Brian Warner]

On 7/10/12 4:38 AM, Greg Troxel wrote:
> 
>   As for connection capability: onion addresses are an 80 bit
>   substring of a public key hash, so that's 80 bits of unguessable
>   [1]. The design doc [2] does not mention a goal such as
>   "undiscoverability" which would be necessary for capabilities (ie:
>   You can only learn an onion by generating one or being told one out
>   of band, but not by sniffing tor introducer or directory service
>   traffic). However, from chatting with tor devs I believe this may be
>   an implemented feature. I'm still browsing source code and specs to
>   see if that's true.
> 
> My gut feeling is that it's a bad idea to use tor addresses as
> capabilities in a system that needs capabilities from other transports.
> Instead, I would treat onion addresses simply as addresses.  I see the
> point about perhaps eking out a bit of efficiency, but I think it adds
> complexity, fragility, and testing difficulty that greatly outweight the
> win.

It's been many years since I looked at this, but I believe the directory
servers (which help translate those 80-bit strings into signed records
that specify the rendezvous point) have full unencrypted copies of those
records, and exchange them with other directory servers. So they're
trivially guessable by at least those servers.

I actually got to chat with the Tor developer working on those directory
servers maybe 7 years ago, and pitched the idea of managing the records
like Tahoe does: encrypt them, .onion address is the key, SHA256(key) is
the storage-index, records are stored on the first N servers in a
permuted list keyed by the storage-index. But I think my enthusiasm and
excessive detail scared him off :-). Also, 80 bits is a compromise
between signing-key length and usable DNS name, and using encrypted
records might require a more difficult compromise.

cheers,
 -Brian