Hacker News Reader

Comment by steveklabnik | Hacker News Reader

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

View on HN

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.

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.

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.

All I know is what's in the post; you're right that "Debian" is not exactly enough info...

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.

I'd expect very few clients to negotiate using SHA-384. It's widely viewed as overkill compared to SHA-256, and it hurts performance.

I'm not saying it invalidates the benchmark results or anything—I just wanted to address your "not used" question.

SHA-384 can actually be faster than SHA-256 is some cases. The reason is that SHA-256 used 64 rounds with 32 bit words, while SHA-384 uses 80 rounds with 64 bit words. So, each block processed by SHA-384 is twice as big but uses less than twice as many rounds.

Oh yes, definitely. But SHA-384's output is 128 bits wider, which uses more bandwidth. Although for the AEAD ciphersuites, it doesn't make much of a difference, admittedly.

There is the not so widely used SHA-512/256 for that case - the speed of the 64 bit variants with a 256 bit output.

Isn't SHA-256 vulnerable to length extension attacks?

Yes, but so is SHA-384 and that is not relevant for the TLS context.

384 is not vulnerable to length extension attacks precisely because it is truncated. The output is not he full internal state.

The speed advantage of SHA-512 and the advantage of truncation is why some more exotic variants like SHA-512/256 (SHA-512 truncated to 256 bits) are used in newer protocols.

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

Reply on news.ycombinator.com