[tor-dev] Interoperation with libp2p

[Jorropo]

Hey, I work for protocol labs (however not in the libp2p team) and I am a
go-libp2p contributor.

> Thinking out loud: NAT traversal can use a rendezvous node, hidden
services are an intriguing option

Yes there have been people who already thought that however, tor doesn't
need to do anything.

I've worked on https://github.com/berty/go-libp2p-tor-transport once (PoC
leaks IPs with DNS requests, no audit, TLDR don't use it).

> This first is to be able to advertise libp2p network in the directory, a
16bit network ID would be sufficient(where about 16 networks could be
advertised).
> The second is to be able to send tor frames that unwrap to libp2p frames
once they reach a node advertising being part of a libp2p network or
networks(by way of using masking bits). I feel the second could be
accomplished with hidden service, but it feels more natural to want an RPC.

If I understand correctly you want for tor clients to be able to dial
libp2p clients because something would advertise and relay libp2p endpoints
in tor's directory ?

That sounds overly complicated and pretty much useless. I mean that looks
cool but if libp2p wants to use tor it can just use tor like anyone else
does (see my transport above), each libp2p node that wants to use tor just
run a tor client, connect to the tor network and register itself in the
directory, then advertise the tor hash in libp2p's DHT, to me this is a way
better solution because that doesn't make libp2p special, everything works
as they are supposed to and keep development efforts to a healthy low.

> IPFS might still be inferior to Tahoe LAFS in real terms, especially due
to lacking erasure coding.

IPFS isn't just a filesharing network, it's a content addressed network
(TL;DR no one owns files, it's a network where you query a hash and it
return you the content that has that hash).
IPFS is in philosophy way closer to bittorrent than Tahoe LAFS, Bittorent
is also a network where you query for hash and you get content that has
that hash and I don't belive anyone ever said that bittorent is bad because
you can't force people to remove your content (actually music and movie
lobby did but I don't think you would agree with them) and for me the same
apply to IPFS.

> Now libp2p doing their own scheme for sending their stuff over Tor’s
existing streams makes sense.

+1

> I’d expect libp2p to be a nightmare of downgrade attacks, given the
amount of badly rolled stuff they must still support, like their dangerous
key exchange SECIO built on the legacy curve sep256k1, but it’ll go deep
than that.

It's really not, we have a fast deprecation cycle, unless you manually
choose to add support for it in your build it's not available anymore, any
software using libp2p right now use tls1.3, noise
<https://github.com/libp2p/specs/blob/master/noise/README.md> or QUIC's
layer (so I believe dtls).

Le mar. 7 déc. 2021 à 19:33, Jeff Burdges <burdges at gnunet.org> a écrit :

>
>
> > On 7 Dec 2021, at 19:26, Jeff Burdges <burdges at gnunet.org> wrote:
> > I advise against allowing any libp2p cruft into tor itself though.
>
> Among the many reasons. I’d expect libp2p to be a nightmare of downgrade
> attacks, given the amount of badly rolled stuff they must still support,
> like their dangerous key exchange SECIO built on the legacy curve sep256k1,
> but it’ll go deep than that.
>
> Jeff
> _______________________________________________
> tor-dev mailing list
> tor-dev at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20211208/bf5dd438/attachment-0001.htm>