[tahoe-dev] switching from introducers to gossip?

[bertagaz at ptitcanardnoir.org]

On Tue, Jul 10, 2012 at 07:38:40AM -0400, Greg Troxel wrote:
> 
>   It seems people are only aware of the last feature because of the
>   poorly chosen name.  IMO, the "hidden" aspect is one of the less
>   interesting features.  I've heard a rumor that there's a proposal to
>   make a version of this feature which provides the other features
>   without the hidden part for the benefit of lower latency.
> 
> 
> An important point is that hidden services consume resources on other
> people's systems, and those systems are volunteered for the purpose of
> providing anonymity.  The use of bittorrent is discouraged over tor, not
> because of philosophical objections, but because the tor network can't
> really handle the load.  So while I think tahoe-lafs should work over
> tor, I don't think it's entirely responsible (to the set of people that
> volunteer tor relays) to suggest routine use of tor merely for firewall
> traversal.

Depends also if efforts are being made by tahoe-lafs users of hidden
services to participate to the Tor network and share bandwidth by setting
up nodes on the network.

For bt, it's quite clear that the Tor network can't be used for that, given
the huge traffic it generates, but also incompatibilities in the bt
protocol that might break anonymity or are resource eaters for the Tor
network. I'm not sure this limitations apply really for tahoe-lafs, which
after all is HTTP, and probably have a lot less bandwidth usage than the bt
networks (for now?).

> That said, it seems connecting to hidden services doesn't require exit
> relay use, so hidden services tread more lightly on the really scarce
> resource; non-exit relays are much easier to come by.
> 
>   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.

I agree that it's already possible to use tahoe-lafs nodes behind hidden
services. I've setup such a network to test if it was possible, and it
worked. It's even probably possible to use a system such as Tails [1] on a
old unused hardware and run a hidden tahoe-lafs node for your backups
using this system's encrypted persistence feature. That's something I'd
like to give a try.

I didn't really checked though if tahoe-lafs was leaking IPs or other
non-anonymous informations, this should be looked closer, but I'm not
much concerned about that.

Also the torproject people are mentoring this year a GSOC named APAF,
which is briefly:

"..., the goal of APAF is to provide an easy system to allow network
related python application developers to build their software in a way
that it runs as a Tor Hidden Service (Tor HS)."

More infos can be found on the full email [2], as well as it's code [3],
by reading the tor-dev mailing list archives, or asking on #tor. I'm sure
they'd be happy to have feedbacks from experienced "python application
developers". Might even be an interesting path to have people easily setup
their hidden tahoe-lafs node.

bert.

[1] https://tails.boum.org
[2] https://lists.torproject.org/pipermail/tor-dev/2012-March/003416.html
[3] https://github.com/mmaker/apaf