Hacker News readers would probably do well to read the actual post: https://jbp.io/2019/07/01/rustls-vs-openssl-performance.html

It also comes with four separate posts that dig into the details, figuring out why the discrepancy exists.

Additionally, rustls is a tls library built on top of ring. ring is a project that is porting BoringSSL to Rust + assembly, bit by bit. BoringSSL was forked from OpenSSL. So there's common code ancestry here, especially around the primitives.

I have heard some people criticize these benchmarks because "those APIs aren't really used" or something; I don't fully understand this criticism myself, but they saw them as being "not real enough."

Very interesting!

Rust normally prevents a lot of memory safety problems, but those are not the only kind of security problem in a crypto system. Obviously the library has to correctly implement the spec (and expectations of users), which just using Rust doesn't guarantee. More importantly, a crypto library also has to avoid leaking crypto data through various side channels. Just using Rust doesn't help with that; "Crypto Coding" at https://github.com/veorq/cryptocoding lists some rules to help address that.

Anyone know if rustls has worked on those issues as well? I notice that rustls uses ring, which asserts on https://github.com/briansmith/ring that "Most of the C and assembly language code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL. ring merges changes from BoringSSL regularly."

It doesn't matter if it's fast if it doesn't do things correctly...!

Impressive. I know Firefox uses NSS (its own TLS library) and not OpenSSL, but this article makes me wonder if Mozilla would consider using rustls in FF as Rust handles more and more of the FF code. Maybe it says something that NSS has few users apart from FF despite the obvious advantage of being maintained by a major organization.

Interestingly, the crypto code in rustls is by ring, a Rust crypto library. According to the ring github page, "Most of the C and assembly language code in ring comes from BoringSSL, and BoringSSL is derived from OpenSSL."

The implication here is that it does better because it's written in rust. I doubt that's the case. I think it's faster because it's new, smaller (i.e. doesn't have to deal w/backwards-compatibility with previous versions or old protocols). More importantly, it uses the ring library for crypto, which is over half asm according to its github. Clearly, there's a lot of optimization there.

Regardless of the reason why, I'm very excited to see a better alternative to openssl. More competition will hopefully make all the projects better, and I wish the rustls guys the best of luck.

How much of these 'lol x written in Rust is better than y' is simply a matter of newer code generically improving on older poorly written software?

Thread from a couple weeks ago: https://news.ycombinator.com/item?id=20352296

If your coding in rust, need ssl, and are cross compiling, using rustls over openssl leads to simpler builds. This helped me simplify the rust -> aws lambda flow on a recent project.

It would be cool if Firefox could switch to Rustls, but I can imagine that it will take a lot of time.

I would be interested in a comparison with BoringSSL.

I like to think that people that brag about how good Rust is like the smell of their own farts. They just get nostrils full of methane every time they quiff one out. Rust replacing C and C++? That's not gonna happen in my opinion. I see Rust replacing C++ in the near future, but not C. C is by far the most flexible, yet powerful programming language I've seen, and no language can even come close to doing what C can. Let's not forget that C is very small and geared towards efficiency. How about instead of making a programming language bulky with tons of mechanisms to prevent human failure, we train humans to not be as prone to causing those failures? I love Rust but man are people smug about it.

Was hardware AES and DH ever used? With hardware AES, it becomes hard to get statistically significant difference in between crypto libraries.

Unless you use a purpose made low CPU usage cipher like salsa 20, hardware crypto is just so much faster than software. It is like comparing software h264 implementations in 2019, and trying to make big news out of it.

Salsa 20 and derivatives looks to me a very promising cypher suite, but for as long as there is no hardware support for it, it will not see its niche even in resource constrained niches as even $5 smartphone SoCs nowadays can run hardware AES faster than any software crypto.

Another moment that needs note is that Salsa is still a relatively new and untried cypher, without much real world track record other than its use in Chrome. Poly1305 is an even less tried construct vs GMAC, with harder to imagine hardware implementation (it will be fair to say that most HMACs are hard nuts to crack for hardware implementation because of them using tons of LUTs.)

Second, Salsa is a work of just 1 man + few collaborators. Knowing the crypto community, this itself may be a reason for push back from it.

P.S. Question to people in crypto: why not to use some derivative of Salsa 20 as an HMAC instead of Poly1305 in Salsa-Poly combo?