4 ms·

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

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

by mises 7y ago

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.