rust-libp2p: ring is a bad dependency; get rid of it
Hello,
I’d like to suggest the removal of ring as a dependency all-together. That also includes rustls and webpki. (rustls is used by the websocket transport)
Why:
- Because I don’t see a point in using that one vs others when it mostly is a wrapper to Assembly code:
- The maintainer is problematic: https://github.com/briansmith/ring/issues/774 and doesnt work in the spirit of Free Software.
- There is no portable fallback for crypto primitives, which means it wont compile on less common platforms, at the mercy of the problematic maintainer.
- The build system of
ringis really a mess.
I suggest using the openssl crate instead. That supports both OpenSSL and LibreSSL and any other library that offers an openssl-compatible interface. Or individual crates that implement the primitives needed by libp2p such as: https://github.com/RustCrypto – but I don’t think they’re that mature yet.
I started porting libp2p crates to openssl but it seems that ring types are exposed in public interfaces, so that would be a breaking change. Also, usage of ring really doesnt seem contained, so it’s not so trivial to do so either.
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 15 (5 by maintainers)
We’re a couple years away from any viable ring and rustls alternatives I think, assuming some qualified crypto devs begin work tomorrow.
Avoid openssl. It’s poorly written and dangerous. I’d expect some yanked ring versions prevent vulnerabilities, but maybe nobody really knows.
We need TLS for transport layer encryption and authentication, which means rustls. SECIO is far worse and should be turned off asap. We need UDP for our parachain piece distribution eventually, maybe some analog of Bittorrent’s uTP. We’ll want QUIC for UDP protocols, meaning more TLS. I’d think all three Rust QUIC implementations use rustls, but the better one quinn definitely does.
RustCrypto provides only symmetric primitives, but not asymmetric primitives, and definitely not the painful and dangerous “agile” crypto demanzded by TLS. All interfaces in RustCrypto require const generics before stabilization. I’m unsure about side channel protections and performance in RustCrypto, well all that crypto gets written in assemble for good reasons. I hear Mozilla should produce RFCs this year for Rust and LLVM support for constant-time code, not sure about the performance impact.
We could/should eventually develop Noise, which avoids TLS’ protocol agility mess, and nQUIC = QUIC+Noise, and ProtocolLabs wants to take that route, but doing so sounds like quite a long road.
I really hope that one day
rustlswill support an optional pure-Rust backend based on the RustCrypto crates. When I was talking with @ctz on IRC (I think it was more than a year ago), he said that he is open to it. I think we are really close to it in terms of implemented primitives, but not quite there yet. Also another blocker is makingwebpkiindependent fromringand unfortunately I am not sure if Brian will be open to that idea.