Interoperation with libp2p
I work on a project that selected libp2p, but only write cryptographic code, not networking code.. I’d caution against using libp2p for anything serious. Protocol Labs always took a pretty sophomoric approach: libp2p managed to be better than ethereum’s but ignored almost everyone working in that space. It devp2p. IPFS might still be inferior to Tahoe LAFS in real terms, especially due to lacking erasure coding. At some point Protocol Labs spun off libp2p, and by then its core devs recognized many of the underlying mistakes. It also benefits from considerable interest but I think our stronger networking people remain unimpressed. It’ always possible to learn from their mistakes of course, but I suspect tor people learned most of those lessons from I2P’s efforts. Now libp2p doing their own scheme for sending their stuff over Tor’s existing streams makes sense. Maybe someone would even pay Tor folk a support contract for the assistance designing that? We've a relatively low bar for grants up to 30k EUR, and more carefully evaluate ones up to 100k EUR, so if any Tor people want to submit a grant for improving the rust libp2p’s Tor usage, then I’ll ask for it to be supported: https://github.com/w3f/General-Grants-Program/ https://github.com/libp2p/rust-libp2p I advise against allowing any libp2p cruft into tor itself though.
On 10 Nov 2021, at 16:26, Mike Mestnik <cheako+torproject_org@mikemestnik.net> wrote: https://gitlab.torproject.org/tpo/core/torspec/-/issues/64
On 7 Dec 2021, at 19:26, Jeff Burdges <burdges@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
FWIW, I don't think libp2p supports SECIO anymore. In fact the (go) repository has been archived: https://github.com/libp2p/go-libp2p-secio and there is no trace of SECIO in the current (go) implementation of libp2p. On Tue, 7 Dec 2021 at 19:33, Jeff Burdges <burdges@gnunet.org> wrote:
On 7 Dec 2021, at 19:26, Jeff Burdges <burdges@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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@gnunet.org> a écrit :
On 7 Dec 2021, at 19:26, Jeff Burdges <burdges@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
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@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@gnunet.org> a écrit :
On 7 Dec 2021, at 19:26, Jeff Burdges <burdges@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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
_______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
participants (5)
-
Holmes Wilson -
Ismail Khoffi -
Jeff Burdges -
Jorropo -
Mike Mestnik