Rustls Multi-Threaded Performance Is Battering OpenSSL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts
  • ayumu
    Senior Member
    • Oct 2008
    • 659

    #31
    But is it actually secure?

    Or does the timing vary depending on the plaintext or key.

    Don't just trust it because rust. It only helps with memory safety.

    Comment

    • oleid
      Senior Member
      • Sep 2007
      • 2504

      #32
      Originally posted by patrick1946 View Post
      Is not aws-lc doing the heavy lifting.
      That's what I wrote. It does for this benchmark.


      Originally posted by patrick1946 View Post
      And is it not written in C++?
      What is wrapped in the rust crate is mostly assembler and some C glue code.

      Originally posted by patrick1946 View Post
      I really ask myself how many of the commenter here have a really deep experience with programming system languages?
      "¯\_(ツ)_/¯"​
      Last edited by oleid; 03 December 2024, 11:44 AM.

      Comment

      • fotomar
        Phoronix Member
        • Jun 2024
        • 93

        #33
        Originally posted by patrick1946 View Post

        So you quote a document from the guy who is not anymore sponsored. Hmm.
        Nobody seems to be refuting it with actual evidence

        Comment

        • sdack
          Senior Member
          • Mar 2011
          • 1724

          #34
          Originally posted by Volta View Post
          The piece of shit called rust will die sooner.
          While I do not like the tone in this discussion, the Rust community is taking a great risk with this particular project. If Rustls shows to be more secure and faster than other implementations, then not much will happen and Rust will continue to claim its usefulness and place. If the Rustls project shows to be as or less secure however, then it will undermine the assumption that using Rust would lead to more secure software. A failure to provide a more secure implementation will have greater consequences for the Rust language and its community. Hopefully will they make sure this is not going to happen but continue to be good competition.

          Comment

          • Almindor
            Senior Member
            • Jul 2008
            • 480

            #35
            Originally posted by sdack View Post
            No better way to stoke the flames through false attribution. As if Rust was magically faster than C/C++ or assembly. It is not. It is simply a false attribution by people trying to create the image it was. It is a newer implementation of SSL, which takes from previous implementations and improves upon these. This can be achieved with C/C++ and assembly, too. What plays a factor here is that the primary criteria of SSL implementations is not speed, but security. It makes it easier to improve upon speed when speed is not the primary concern of users. In return can one ask how secure Rustls is. We already know OpenSSL is worse than LibreSSL in terms of security. What should not be done is to assume Rustls was more secure, making it another false attribution. Security has to remain the dominant factor and should not be implied based on what language was used. It is however good to see competition, because it may lead to improvements in security, speed, compatibility and other factors.
            But Rust is faster than C/C++ at least in one case, due to the language having better type and argument information leading to a possibility of optimization that cannot be done with C/C++. Mutable pointer aliasing optimizations have been possible on Rust for many years, but ironically because they're not possible for C/C++ the optimization path was broken in LLVM (C++ code, double irony).

            There are other hidden nuances like this that allow optimizations impossible in most other languages.

            Comment

            • reba
              Senior Member
              • May 2020
              • 676

              #36
              Originally posted by sdack View Post
              This can be achieved with C/C++ and assembly, too.
              Of course everything what can be done with Rust can be done with C, C++ and Assembly. And bitpushing and with punchcards, ...

              That's no argument. The question is however, are you, as a developer, with Rust, C, C++ or Assembly: faster, more productive, do you create robuster code, have better tool support, a better ecosystem, etc.
              And for that question you do not get R = C = Cpp = A but more like R > C(pp) > C(pp) > A or alike, answered different for every of the above aspects, but with a high propability of R being on the left side of an >

              Comment

              • Almindor
                Senior Member
                • Jul 2008
                • 480

                #37
                Originally posted by patrick1946 View Post

                So you quote a document from the guy who is not anymore sponsored. Hmm.
                Communists also made "enemies of the state" by removing anyone who they disliked from "sponsorships". It worked well with fools who gobble up all the official stuff. I don't see why I wouldn't believe an individual with years of volunteering in a case like this, especially in today's snowflake climate.

                Got a counter-argument source btw, or do you just go by "well he's not sponsored anymore so what he says must be false" ?

                Comment

                • Laser
                  Phoronix Member
                  • Jun 2011
                  • 58

                  #38
                  Originally posted by sdack View Post
                  No better way to stoke the flames through false attribution. As if Rust was magically faster than C/C++ or assembly. It is not. It is simply a false attribution by people trying to create the image it was. It is a newer implementation of SSL, which takes from previous implementations and improves upon these. This can be achieved with C/C++ and assembly, too. What plays a factor here is that the primary criteria of SSL implementations is not speed, but security. It makes it easier to improve upon speed when speed is not the primary concern of users. In return can one ask how secure Rustls is. We already know OpenSSL is worse than LibreSSL in terms of security. What should not be done is to assume Rustls was more secure, making it another false attribution. Security has to remain the dominant factor and should not be implied based on what language was used. It is however good to see competition, because it may lead to improvements in security, speed, compatibility and other factors.
                  Right. Performance benchmarks for cryptographic libraries are… surely not unimportant, but also not of the highest priority.

                  Though, this only implements TLS as far as I see… and the cryptographic primitives are actually in ring, so stuff like side channel attacks on the relevant ciphers isn't this problems fault. The later mentioned audit report is rather thin (basically "we looked at the code and it's great!", not that I don't believe it but also just a summary)

                  Comment

                  • sandain
                    Phoronix Member
                    • Oct 2007
                    • 109

                    #39
                    Originally posted by cynic View Post
                    well, the Rust community is not much better in that regard: it's full of people with couloured hairs and pronouns in bios.
                    also, did you forget about the recent Rust Foundation dramas?
                    Serious question here: what is wrong with putting pronouns in bios? I personally work with a lot of people from different backgrounds from my own, and I have a hard time knowing which pronouns to use based on names alone, especially for non-western names. I'm not even talking about the cis/trans culture war going on right now -- I just prefer to avoid misgendering colleagues and clients I've only met over email.

                    Comment

                    • Weasel
                      Senior Member
                      • Feb 2017
                      • 4500

                      #40
                      Originally posted by Almindor View Post
                      But Rust is faster than C/C++ at least in one case, due to the language having better type and argument information leading to a possibility of optimization that cannot be done with C/C++. Mutable pointer aliasing optimizations have been possible on Rust for many years, but ironically because they're not possible for C/C++ the optimization path was broken in LLVM (C++ code, double irony).

                      There are other hidden nuances like this that allow optimizations impossible in most other languages.
                      What do you mean by mutable pointer aliasing optimizations?

                      C/C++ have strict aliasing rules and it's been the default in GCC for ages now. Code that wants to alias different types needs to either use union type punning (an extension NOT part of the standard) or use the may_alias attribute. Both are non standard but work ok. But by default, it optimizes different types as if they don't alias, except for char.

                      And for optimizing same types that don't alias you can use restrict in C. In C++ you have to use __restrict__ in GCC because it's non-standard (you can define it to restrict with macro though, but end up polluting the global namespace).

                      Comment

                      Working...
                      X