Is not rustls a mix of c++, assembly and rust ?
I think it’s not a good indication of the success of the language.
I think it’s not a good indication of the success of the language.
It's not practical right now to write high performance cryptographic code in a secure way (e.g. without side channels) in anything other than assembly.
Regarding crypto operations, I know as of now for rust projects assembly is a must to have constant time guarantees.
Maybe there could be a way with intrinsics and a constant-time marker, similar to unsafe, to use pure rust.
In the meantime I think there still is too much C code.
It’s a great step in the good direction by the way.
From the AWS-LC README: https://github.com/aws/aws-lc
> A portable C implementation of all algorithms is included and optimized assembly implementations of select algorithms is included for some x86 and Arm CPUs.
It also states that it kind of forked BoringSSL and OpenSSL.
You’re right though that most of the memory safety attack surface has been replaced with Rust.
Ideally the C would eventually move to Rust, but I think aws-lc needs to work in many contexts where a Rust toolchain is not available so it might be a while.
Graviola is an interesting option under development, in part because it gets rid of the C:
TLS is the protocol generation and parsing, hopefully (but not always) including certificate parsing.
Crypto tends to have clear, fixed buffer sizes, and OpenSSL tends to have good implementations of it with reasonable interfaces.
Protocol parsing and certificate parsing and validation are where many more problems happen that memory safety can reduce. High profile crypto problems are generally information leaks from non-constant time algorithms leaking information; although information leaks also happen from protocol code too.
Even if unrestricted asm is inherently unsafe, there's got to be a subset of instructions and operand types you can guarantee is safe if called a certain way.