4 ms·
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 th
by dwheeler 7y ago
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...!
- gnode 7y agoInevitably 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.
- PyroLagus 7y agoYou 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 https://github.com/project-everest/vale [1] https://mitls.org/ https://mitls.org/
- pcwalton 7y agoBrian Smith is well-regarded as an expert in this field. He knows what he's doing.
- drenvuk 7y agoJust trusting a name and not the product has led to some bad outcomes before.
- bluejekyll 7y agoHaving 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.
- tptacek 7y agoCan 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.
- tedunangst 7y agoI 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.
- drenvuk 7y agoNot a single one.
- ori_b 7y agoYeah, 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.
- mschuster91 7y agoThe 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.
- ori_b 7y agoWhich ones?
- tptacek 7y agoNote 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 7y agoI’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.
- libeclipse 7y agoI wonder if the performance gains are due to BoringSSL being faster than OpenSSL?
- steveklabnik 7y agoI 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.
- kevin_thibedeau 7y agoX.509 parsing has no allocations and call depth is significantly less than OpenSSL.
- steveklabnik 7y agoThat’s very cool!
- m463 7y agoI 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.