A Rust-based TLS library outperformed OpenSSL in almost every category

A small nit that bugs me in the original post

> The difference between AES128 and AES256 appears to be approximately 26%, rather than the 40% one might expect (AES128 does 10 rounds, AES256 does 14 rounds). There may be some limiting factor that prevents AES128 running at the expected speed, or perhaps this CPU has extra area dedicated to making AES256 faster.

The hardware in the CPU performs a single AES round, it does not dedicate more hardware for AES256. One who understands that AES-GCM is not just AES knows that the difference is due to the GCM overhead, that is the same for 128 and 256.

Did you find where they talked about what configuration options were given to OpenSSL? The benefit and curse of complexity is that OpenSSL can run on everything so what config options are used are very important. I struggle to feel like this is a reproducible benchmark as 'default options' for OpenSSL turns into a whole lot of autoconfiguration depending on the host OS detected and I am not sure what version of Debian they are using for this test and how that was configured (stock or otherwise).

What would have also been nice if there were packet dumps from each to see if there was anything interesting there as well. If it is like you say based on BoringSSL it would be interesting if rust did something different at the packet handling level that OpenSSL did not.

How is the "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA38" cipher suite test "not used". Thats just BS, 22% performance is pretty big.

and 42% performance increase in TLS 1.3 handshakes is even bigger.

Instead of rewriting BoringSSL bit by bit wouldn't it be better to just write a modern and much simpler Noise library?

Inevitably some crypto primatives must be written in assembly languages in order to ensure timing attacks and alike are not possible. As far as I know, there's no support in Rust or C for requiring such constraints from the code generation.

Still, ensuring the code around the primitives is safe in various ways is still valuable.

Brian Smith is well-regarded as an expert in this field. He knows what he's doing.

I am unfamiliar with any of the code, so take my statement with a grain of salt.

Sometimes crypto code must be written in weird ways to fend off attacks.

For example, to prevent timing attacks, code must sometimes be written to take constant time. This basically means that some loops must not exit early (such as when a key is wrong). Instead they must note the failure, then continue looping and return failure afterwards.

This means some code has to be written to always take worst-case time.

But if worst-case time in one libraray is better than another library, there can definitely be improvements.

Yeah, but not surprising: OpenSSL is generally considered to be rather poorly written, from reinventing their own memory allocators, poorly, to layers upon layers of performance-sucking wrappers, to just bizzare and convoluted design decisons.

I'd be far more interested in seeing comparisons to, eg, BearSSL.

I wonder if the performance gains are due to BoringSSL being faster than OpenSSL?

I'd much rather see Firefox use miTLS[0]. They already use HACL[1] (miTLS and HACL are part of Project Everest[2]) in NSS[3], so I don't think it would be too big of a leap. Rust is really cool, but if you want to ensure that the implementation adheres to the spec, a language with formal verification is much better. That said, miTLS isn't finished yet, so of course it's going to take a while until anyone can actually use it.

[0] https://mitls.org/

[1] https://github.com/project-everest/hacl-star

[2] https://project-everest.github.io/

[3] https://blog.mozilla.org/security/2017/09/13/verified-crypto...

Chromium uses NSS too, at least on some platforms. I've also seen it in embedded Linux contexts, it's more common than you think it is.

I've suspected for a long time that Rust would prove to be a faster language than C++ once it was done, but only as the code scales up. On a line-by-line basis, the two languages are comparable, so microbenchmarks will never show it, but Rust will tend to very, very strongly encourage better architectures that require you to do less copying just to be safe. It's really hard to measure "architectural affordances", though... heck, it's hard to even define them, let alone benchmark them.

OpenSSL has been optimized extensively, so I consider the fact that any hobbyist project with a fraction of the resources able to beat it by that much to be significant in a way that, say, beating "some guy's github json parser" isn't. If I were going to temper my excitement, though, what I'd want is to make sure the Rust implementation isn't unknowingly trading away important security considerations to get that speed, such as whatever constant-time operations may be necessary or guarantees about when the key will be destroyed or whatever. I have no concrete knowledge about that in this specific case, but in a security context it is something I'd want to check in general. OpenSSL has had its stumbles, and the architecture is... debateable, especially when binding to it in a non-C language... but it has also been reviewed a lot, and battle-tested, and a lot of other things this little library just hasn't been yet. (Not because of any deficiency of the library, author, or language, but just, something things can only come from time and scale.)

That's not how I read the title. I think it's impressive that it's faster despite being written in Rust.

Maybe Rust also makes it easier to write fast code (I couldn't say one way or another), but it's great that you at least don't need to sacrifice performance on the altar of safety.

I’m generally positive on rewriting openssl in rust, but agree the comparisons aren’t completely scientific or necessarily more important than correctness. First you should compare performance using the same implementations of cryptographic primitives as these are relatively easily fungible. We also don’t know if for example OpenSSL optimised primitives were used. Secondly the rust language only excludes memory bugs, it doesn’t exclude errors in the implementation of the tls protocol or incorrect usage of cryptographic primitives which can be just as catastrophic for security. These have been prevalent in OpenSSL and are somewhat harder to prevent a priori. For all we know these issues are worse for rustls than OpenSSL. This is where formally verified implementations would be useful.

Crypto libraries is a domain where the advantages of Rust are very important. You need really good performance, and you need really good safety guarantees. Rust is relatively unique in being able to deliver both of those as well as it does.

There are probably a lot of reasons why it's faster, and at least some of those are about rust, and some definitely aren't.

https://www.youtube.com/watch?v=aHMRFZkXq4Y

Here's a good talk about the project. Some of the patterns the author uses are sort of hard to do in other languages (such as pattern matching on composite states).

People do good things with rust. Therefore rust is a good programming language.

Could someone have done this particular good thing in another language? Absolutely. But that's not very relevant.

We're not talking about taking a venerable tool that's been sitting around for years and rewriting it though. We're talking about an actively-maintained and extremely highly-used library. I'm sure it's still bogged down by tech debt, but I'm also sure that any easy performance wins have already been taken.

Even if that was all that is there, "x is better than y and written in a language that makes some kinds of bugs much less likely" is still great news for all current users of y. I read "rust-based" as an endorsement of the software, not of the language.

Plenty of them. Is there something to suggest that applies in this case?

Almost all of them but HN loves jumping on the bandwagon.

I'd prefer it to be a bit more battle-hardened before going into a widely used browser.

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.

Daniel J. Bernstein, to be precise, also author of Djbdns, Qmail, NaCl, Curve25519, ... Some of which he solo authored. So I'd take the quoted skepticism with a huge grain of salt.

A lot of the benchmarking focused on handshaking, which is asymmetric cryptographic performance. As far as I know acceleration for asymmetric algorithms specifically is uncommon, although general SIMD instructions can improve performance.