[tor-dev] Interoperation with libp2p

[Holmes Wilson]

One thing I'm excited about for libp2p/tor is Arti.

It seems like Arti, when it's ready, will make it much easier to build a
fully functional and audited Tor client into a libp2p transport.

On Sun, Mar 20, 2022, 4:23 PM Jorropo <jorropo.pgm at gmail.com> wrote:

> 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
>>
> _______________________________________________
> 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/20220406/0a093f1a/attachment.htm>