
A Rust-based TLS library outperformed OpenSSL in almost every category - tene
https://www.zdnet.com/article/a-rust-based-tls-library-outperformed-openssl-in-almost-every-category/
======
steveklabnik
Hacker News readers would probably do well to read the actual post:
[https://jbp.io/2019/07/01/rustls-vs-openssl-
performance.html](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."

~~~
thecompilr
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.

~~~
ctz
This is always a risk with blogging: you say something shortsighted or silly
and don't realise until someone says "eh?" in a public forum. I've removed
that paragraph; thank you for the correction.

------
dwheeler
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](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](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...!

~~~
ori_b
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.

~~~
tptacek
Note well: that was the prevailing (and probably correct) opinion a few years
ago, but OpenSSL's quality has by most accounts improved dramatically over the
last few years. I wouldn't talk someone out of using BearSSL, but if you're
writing code that has to depend on a C-language TLS library, OpenSSL is a sane
first choice.

~~~
bluejekyll
I’ve reviewed OpenSSL code somewhat recently and agree that it’s vastly
improved.

Though, if you want something based on Rustls with C bindings (I have no
involvement in this project) there is: [https://github.com/mesalock-
linux/mesalink](https://github.com/mesalock-linux/mesalink)

That’s OpenSSL compatible bindings into Rustls.

------
Panino
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."

~~~
PyroLagus
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/](https://mitls.org/)

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

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

[3] [https://blog.mozilla.org/security/2017/09/13/verified-
crypto...](https://blog.mozilla.org/security/2017/09/13/verified-cryptography-
firefox-57/)

~~~
earenndil
It looks like it's written in F#; that would make it harder to integrate with
mozilla's c++/rust codebase. Not impossible surely, but possibly not worth it
since in general an attacker has far more interesting avenues of attack than
the ssl implementation; especially since it hasn't AFAIK had any high-profile
vulnerabilities.

~~~
forty
F* not F#
[https://en.m.wikipedia.org/wiki/F*_(programming_language)](https://en.m.wikipedia.org/wiki/F*_\(programming_language\)).
It compiles to C.

~~~
kitd
From the linked project page:

 _The stable version of miTLS including the new 0.9 release are written in F#
and specified in F7._

Excuse my confusion.

------
mises
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.

~~~
jeffdavis
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.

~~~
xiphias2
> Could someone have done this particular good thing in another language?
> Absolutely

While this is true for many other tasks, I don't think there exists any other
programming language that fits so well for safe and efficient protocol
implementation (where experimentation speed is not that important)

------
cybersnowflake
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?

~~~
eridius
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.

~~~
kroeckx
A lot of time is spend on the assembler versions doing the crypto, which is
why they get used by various other projects like ring, boringssl, and the
Linux kernel.

Less or no time is spend on improving the performance of the SSL library. From
the article, it seems that the SSL library might have easy fixes.

~~~
eridius
From the article it sounds like there are some simplistic reasons why OpenSSL
may be slower, such as making an extra copy of the plaintext, but that doesn't
necessarily mean that fixing it is easy.

------
dang
Thread from a couple weeks ago:
[https://news.ycombinator.com/item?id=20352296](https://news.ycombinator.com/item?id=20352296)

------
dhbradshaw
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.

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

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

~~~
phaedryx
Agree. I'd rather have safe/secure over speed in this case.

------
hcnews
I would be interested in a comparison with BoringSSL.

------
baybal2
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?

~~~
Fnoord
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.

