Hacker News Reader

Comment by dwheeler | Hacker News Reader

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

View on HN

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.

You could write those in Vale[0], but at that point, just use miTLS[1] to have a completely verified TLS implementation.

[0] https://github.com/project-everest/vale

[1] https://mitls.org/

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

Just trusting a name and not the product has led to some bad outcomes before.

Having worked with Brian while integrating ring into Trust-DNS, I concur with the assessment from pcwalton.

But, yes, the name isn’t the only thing, but the discourse on the development of ring through the issue discussion on Github is high quality and very conservative in what is accepted. The library is high quality and has decent test coverage, with a diligent review process. All of that stems from Brian’s effort in maintaining an amazing project.

Can you provide an example of a name trusted among cryptographers, a specific library, and a bad outcome? I agree with Patrick Walton: Brian Smith is an extremely credible engineer in this particular domain.

I would venture, tentatively, the hypothesis that the exact opposite thing is true, and that trusting well-established subject matter experts has been a pretty good strategy in cryptographic security. There's a reason everyone uses Sodium/Nacl.

I think the subject is somewhat ambiguous because for many users, they are more likely to recognize library author names than cryptographers. And imagine those authors are cryptographers in their own right.

Not a single one.

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.

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.

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

That’s OpenSSL compatible bindings into Rustls.

The thing is openssl runs on so many platforms, which may or may not guarantee anything except a barely working malloc/free, so it makes sense to ship a custom allocator.

Which ones?

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

I linked to the in-depth explanations below; it has stuff like

> The difference between OpenSSL and rustls appears to be thanks to an extra copy in the main data-path in OpenSSL.

and

> It appears OpenSSL recalculates and then discards the local public key when processing the server’s key share extension. This likely explains the larger performance deficit in this test.

in it. So I doubt that it's the result of differences in the primitives.

X.509 parsing has no allocations and call depth is significantly less than OpenSSL.

That’s very cool!

Reply on news.ycombinator.com