The ciphers and hashes from OpenSSL have almost always been good C code. I'm sure there have been issues with variable runtimes leaking information, but memory safety won't be a cipher problem.
The protocol code, and the x.509 code from OpenSSL hasn't always been great. Rust providing memory protection on that is a nice thing.
There's certainly a question of how that makes for significantly more performance; handshake performance is usually dominated by crypto performance, and the same for data transfer... so if the crypto is coming from the same library, it's unexpected to see such a big change (10%+ in most graphs by my eye?)
Seems like it would be interesting to take one of these and really dig into it. That said, I know OpenSSL 3 was having some performance issues in some applications because of new locking behaviors; I don't know if BoringSSL took those or not.
Comments
The ciphers and hashes from OpenSSL have almost always been good C code. I'm sure there have been issues with variable runtimes leaking information, but memory safety won't be a cipher problem.
The protocol code, and the x.509 code from OpenSSL hasn't always been great. Rust providing memory protection on that is a nice thing.
There's certainly a question of how that makes for significantly more performance; handshake performance is usually dominated by crypto performance, and the same for data transfer... so if the crypto is coming from the same library, it's unexpected to see such a big change (10%+ in most graphs by my eye?)
Seems like it would be interesting to take one of these and really dig into it. That said, I know OpenSSL 3 was having some performance issues in some applications because of new locking behaviors; I don't know if BoringSSL took those or not.