Replies: 15 comments
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
LibreSSL is here to fix that. And the |
Beta Was this translation helpful? Give feedback.
-
|
Also, this could look like an alternative: https://github.com/google/tink |
Beta Was this translation helpful? Give feedback.
-
|
Someone has started porting already, but gave up, apparently. https://github.com/denim2x/tink/tree/rust/rust |
Beta Was this translation helpful? Give feedback.
-
|
Tink's roadmap says nothing about TLS, handshakes, key exchange, etc., so afaik not relevant. We'd ideally want everything except TLS 1.3 disabled, but LibreSSL only supports TLS 1.3 for clients, not yet servers: libressl/portable#228 I'd worry that LibreSSL might inherits far more bugs from OpenSSL than BoringSSL does, but maybe not. Aside from rustls, your choices are NSS, miTLS, and BoringSSL, according to https://github.com/tlswg/tlswg-wiki/blob/master/IMPLEMENTATIONS.md GnuTLS sounds worse than OpssenSSL. And picotls uses OpenSSL. CycloneSSL only supports 32 bit architectures. Ain't clear if wolfSSL runs properly on powerful CPUs either. In essence, ring provides an idiomatic safe rust interface into BoringSSL's crypto primitives, so anything more direct will be much worse. I'd expect Mozilla has okay but not idiomatic NSS bindings somewhere. I think miTLS sounds interesting, but maybe slow. I'd think a ring fork sounds easiest in the short term, assuming the problem really warrants so much work. I'd think optional native rust code could support additional architectures, but one must avoid side channel attacks, downgrade attacks, etc., otherwise you only made our problems worse. I suspect rustls shall remain the favored TLS library within the Rust ecosystem: https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html |
Beta Was this translation helpful? Give feedback.
-
Why exactly?
wolfSSL also has an OpenSSL compatible API. Also wolfSSL supports the NTRU quantum-resistant scheme, which is interesting for libp2p.
This is why I suggest OpenSSL/LibreSSL. TLS 1.3 support in LibreSSL will come soon enough.
Extreme performance is not much of a concern for everyone. About QUIC: quinn: "Pluggable cryptography, with a standard implementation backed by rustls and ring" -- which means it should be quite trivial to add another backend. |
Beta Was this translation helpful? Give feedback.
-
|
You're suggesting we move away from the TLS implementation favored by the Rust ecosystem and instead use C bindings far more pervasively and less safely. It's clear doing this would increase our long term maintenance costs, increase our vulnerability surface, and complicate others developing on libp2p and substrate. It appears quinn has traits for cryptography in https://docs.rs/quinn/0.5.2/quinn/crypto/index.html but those traits appears slightly ad hoc and lack any impl, and all quinn's cryptographic types wrap rustls types. I think crypto traits should wait for const generics to stabilize, so quinn supporting anything besides rustls sounds unlikely anytime soon. It appears ring paused the mass yanks after 0.14, although more yanking could follow the the next applicable CVE or BoringSSL churn from Google, but right now everything looks fine. If more mass yanks happen, someone could attempt a semver trick ring 0.17+ wrapper for ring 0.15, 0.16, etc., like the rand project uses, which maybe ring would publish, but regardless if wrappers work then forks or It's possible the Rust Security WG might curtail the yanking rust-secure-code/wg#16 somewhat by providing other avenues. All crates should behave slightly more like ring, in that CVEs should propagate downstream automatically, and the security WG exists to make this happen sanely. I'd think CVEs should eventually cause cargo warnings, even when maintainers keep the insecure version up. p.s. I do not think NTRU support sounds relevant right now. All well maintained TLS implementations should adopt the results of the NIST post-quantum competition, but currently all we know is https://csrc.nist.gov/news/2019/pqc-standardization-process-2nd-round-candidates |
Beta Was this translation helpful? Give feedback.
-
|
Just to note: It's not only about the mass yanks, as mentionned earlier. More so, portability. And the yanks they made werent for security vulnerabilities, they were a way to create attention and virtual incentive towards purchasing the maintainer's support contracts. |
Beta Was this translation helpful? Give feedback.
-
|
I do agree ring should add pure rust backup implementations, but maybe side channel protections caused concerns. If so, there are the upcoming RFCs for better constant-time code generation in Rust and LLVM, which makes non-assembler implementations safer. In the short term, one could actually do a ring-on-dalek fork that uses curve25519-dalek and ed25519-dalek for everything asymmetric, and RustCrypto for everything symmetric. It restricts the cipher suits considerably, and symmetric stuff gets slower, but doing this sounds far easier than using C bindings everywhere. Afaik, we're already using pure rust crates like dalek, etc. for anything in substrate itself that likes strange platforms, like non-browser WASM or SGX. I've no idea if/why libp2p should run on those platforms, although it's obviously nice. It appears code for these platforms exists in some cases, so again forks work fine. It's clearly claimed that some mass yanks stemmed from churn in boringssl, so those comments actually say he wont audit google's assembler changes, which sounds perfectly reasonable. |
Beta Was this translation helpful? Give feedback.
-
Actually, only That said, This should be closed as “won’t fix”. |
Beta Was this translation helpful? Give feedback.
-
|
Very informative, thank you. If we ever need a fix I think the easiest would simply be a ring fork that merges some of the numerous PRs that Brian Smith rejects for not being constant-time enough or whatever. We're not the only ones with this issue, so others contribute to such a fork too. I think @tomaka can say if and when that should happen since he is the main one running libp2p in strange places. |
Beta Was this translation helpful? Give feedback.
-
|
I really hope that one day |
Beta Was this translation helpful? Give feedback.
-
|
@newpavlov I would be more than willing to fork |
Beta Was this translation helpful? Give feedback.
-
|
That said, a lot of cryptographic code is hand-written assembler for good reasons. The fastest ChaCha20 implementation I am aware of is a formally verified assembler version (generated via the verified Jasmine compiler, IIRC). Not using optimized implementations means a significant performance hit. |
Beta Was this translation helpful? Give feedback.
-
|
What is the status of miTLS? It is formally verified and is by far my preferred option if it is of production quality yet. |
Beta Was this translation helpful? Give feedback.
-
Hello,
I'd like to suggest the removal of
ringas a dependency all-together. That also includes rustls and webpki. (rustls is used by the websocket transport)Why:
ringis really a mess.I suggest using the
opensslcrate 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 bylibp2psuch as: https://github.com/RustCrypto -- but I don't think they're that mature yet.I started porting
libp2pcrates toopensslbut it seems thatringtypes are exposed in public interfaces, so that would be a breaking change. Also, usage ofringreally doesnt seem contained, so it's not so trivial to do so either.Beta Was this translation helpful? Give feedback.
All reactions