10 ms·

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

214 points by tene 7y ago

mises 7y ago
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 7y ago
  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 7y ago
    > 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)
  - zaphar 7y ago
    Given enough time and resources someone could do equivalent work in assembly. The point of Rust is that it should take you less time and resources to do so.
- vitriol83 7y ago
  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.
  - staticassertion 7y ago
    > 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. I linked to a talk about the project elsewhere and it's worth noting that the author of rustls leverages a lot of rust techniques that ensure certain correctness attributes at a semantic level, not just memory safety. In particular, TLS libraries have long suffered from dealing with the complex composite state machines required by the protocol[0]. Rust makes the expression of safe state machines pretty easy (the talk demonstrates how). [0]https://www.mitls.org/pages/attacks/SMACK https://www.mitls.org/pages/attacks/SMACK
- staticassertion 7y ago
  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 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).
- gameswithgo 7y ago
  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.
- jerf 7y ago
  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.)
  - fbmac 7y ago
    Rust already beat C in the benchmarks game https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
    - igouy 7y ago
      That boxplot shows both the C and the C++ programs ahead of the Rust programs, so why do you say "Rust already beat C" ?
- buu700 7y ago
  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.
xiphias2 7y ago
It would be cool if Firefox could switch to Rustls, but I can imagine that it will take a lot of time.
- kitd 7y ago
  I'd prefer it to be a bit more battle-hardened before going into a widely used browser.
  - phaedryx 7y ago
    Agree. I'd rather have safe/secure over speed in this case.
Panino 7y ago
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 7y ago
  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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...
  - earenndil 7y ago
    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 7y ago
      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.
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 ago
  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.
  - PyroLagus 7y ago
    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 https://github.com/project-everest/vale [1] https://mitls.org/ https://mitls.org/
- pcwalton 7y ago
  Brian Smith is well-regarded as an expert in this field. He knows what he's doing.
  - drenvuk 7y ago
    Just trusting a name and not the product has led to some bad outcomes before.
steveklabnik 7y ago
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."
- xemdetia 7y ago
  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.
  - deleted 7y ago
    [deleted]
  - steveklabnik 7y ago
    All I know is what's in the post; you're right that "Debian" is not exactly enough info...
- thecompilr 7y ago
  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.
baybal2 7y ago
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?
- gnode 7y ago
  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.
- Fnoord 7y ago
  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.
totothetoro 7y ago
I like to think that people that brag about how good Rust is like the smell of their own farts. They just get nostrils full of methane every time they quiff one out. Rust replacing C and C++? That's not gonna happen in my opinion. I see Rust replacing C++ in the near future, but not C. C is by far the most flexible, yet powerful programming language I've seen, and no language can even come close to doing what C can. Let's not forget that C is very small and geared towards efficiency. How about instead of making a programming language bulky with tons of mechanisms to prevent human failure, we train humans to not be as prone to causing those failures? I love Rust but man are people smug about it.
- inamberclad 7y ago
  There was an article from Microsoft on why they're adopting Rust that was posted a little bit ago. The gist of it is that even with a skilled staff, 70% of their CVEs were due to memory errors.
  - geofft 7y ago
    Right - the whole point of having computers / machines is to reliably and efficiently do things that humans are bad at doing at scale. I honestly don't understand people who are excited about programming and also excited about doing things by hand that computers can do better and faster. Like, what is the appeal of programming to them?
    - Polyisoprene 7y ago
      Enjoying debugging their code? :)
  - xkLA 7y ago
    The article was not from Microsoft but from some rag like ZDNet (I think it was also ZDNet, in which case they're currently submarine-ing Rust). 70% of CVEs are C/C++, because those bugs need to be fixed and important things run on C/C++. It is an entirely useless metric.
hcnews 7y ago
I would be interested in a comparison with BoringSSL.
cybersnowflake 7y ago
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?
- lilyball 7y ago
  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 7y ago
    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 7y ago
      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.
  - llukas 7y ago
    Highly used yes. But there are only two full time developers on this and funding was flakey. There was giant discussion about this during Heartbleed vulnerability.
    - eridius 7y ago
      That's true, but performance improvements don't require fulltime developers. Many companies are directly impacted by OpenSSL performance (maybe moreso in the past when a big question about HTTPS adoption was the performance overhead of adding SSL to all requests, whereas today it's generally considered not a problem) which means companies have an incentive to submit patches to fix identifiable performance issues.
dang 7y ago
Thread from a couple weeks ago: https://news.ycombinator.com/item?id=20352296 https://news.ycombinator.com/item?id=20352296
dhbradshaw 7y ago
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.

214 points by tene 7y ago

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 7y ago
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 7y ago
  > 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)
- zaphar 7y ago
  Given enough time and resources someone could do equivalent work in assembly. The point of Rust is that it should take you less time and resources to do so.
vitriol83 7y ago
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.
- staticassertion 7y ago
  > 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. I linked to a talk about the project elsewhere and it's worth noting that the author of rustls leverages a lot of rust techniques that ensure certain correctness attributes at a semantic level, not just memory safety. In particular, TLS libraries have long suffered from dealing with the complex composite state machines required by the protocol[0]. Rust makes the expression of safe state machines pretty easy (the talk demonstrates how). [0]https://www.mitls.org/pages/attacks/SMACK https://www.mitls.org/pages/attacks/SMACK
staticassertion 7y ago
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 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).
gameswithgo 7y ago
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.
jerf 7y ago
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.)
- fbmac 7y ago
  Rust already beat C in the benchmarks game https://benchmarksgame-team.pages.debian.net/benchmarksgame/which-programs-are-fastest.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
  - igouy 7y ago
    That boxplot shows both the C and the C++ programs ahead of the Rust programs, so why do you say "Rust already beat C" ?
buu700 7y ago
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.

xiphias2 7y ago

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

kitd 7y ago
I'd prefer it to be a bit more battle-hardened before going into a widely used browser.
- phaedryx 7y ago
  Agree. I'd rather have safe/secure over speed in this case.

Panino 7y ago

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 7y ago
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-cryptography-firefox-57/ https://blog.mozilla.org/security/2017/09/13/verified-crypto...
- earenndil 7y ago
  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 7y ago
    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.

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 ago
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.
- PyroLagus 7y ago
  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 https://github.com/project-everest/vale [1] https://mitls.org/ https://mitls.org/
pcwalton 7y ago
Brian Smith is well-regarded as an expert in this field. He knows what he's doing.
- drenvuk 7y ago
  Just trusting a name and not the product has led to some bad outcomes before.

steveklabnik 7y ago

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

xemdetia 7y ago
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.
- deleted 7y ago
  [deleted]
- steveklabnik 7y ago
  All I know is what's in the post; you're right that "Debian" is not exactly enough info...
thecompilr 7y ago
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.

baybal2 7y ago

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?

gnode 7y ago
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.
Fnoord 7y ago
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.

totothetoro 7y ago

I like to think that people that brag about how good Rust is like the smell of their own farts. They just get nostrils full of methane every time they quiff one out. Rust replacing C and C++? That's not gonna happen in my opinion. I see Rust replacing C++ in the near future, but not C. C is by far the most flexible, yet powerful programming language I've seen, and no language can even come close to doing what C can. Let's not forget that C is very small and geared towards efficiency. How about instead of making a programming language bulky with tons of mechanisms to prevent human failure, we train humans to not be as prone to causing those failures? I love Rust but man are people smug about it.

inamberclad 7y ago
There was an article from Microsoft on why they're adopting Rust that was posted a little bit ago. The gist of it is that even with a skilled staff, 70% of their CVEs were due to memory errors.
- geofft 7y ago
  Right - the whole point of having computers / machines is to reliably and efficiently do things that humans are bad at doing at scale. I honestly don't understand people who are excited about programming and also excited about doing things by hand that computers can do better and faster. Like, what is the appeal of programming to them?
  - Polyisoprene 7y ago
    Enjoying debugging their code? :)
- xkLA 7y ago
  The article was not from Microsoft but from some rag like ZDNet (I think it was also ZDNet, in which case they're currently submarine-ing Rust). 70% of CVEs are C/C++, because those bugs need to be fixed and important things run on C/C++. It is an entirely useless metric.

hcnews 7y ago

I would be interested in a comparison with BoringSSL.

cybersnowflake 7y ago

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?

lilyball 7y ago
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 7y ago
  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 7y ago
    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.
- llukas 7y ago
  Highly used yes. But there are only two full time developers on this and funding was flakey. There was giant discussion about this during Heartbleed vulnerability.
  - eridius 7y ago
    That's true, but performance improvements don't require fulltime developers. Many companies are directly impacted by OpenSSL performance (maybe moreso in the past when a big question about HTTPS adoption was the performance overhead of adding SSL to all requests, whereas today it's generally considered not a problem) which means companies have an incentive to submit patches to fix identifiable performance issues.

dang 7y ago

Thread from a couple weeks ago: https://news.ycombinator.com/item?id=20352296 https://news.ycombinator.com/item?id=20352296

dhbradshaw 7y ago

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.