[fulafel]

From safety point of view that's actually good enough for "perfect is the enemy of good" to apply here.

Cryptographic primitives are much much safer in C (and assembly) than protocol handling, certificates etc.

They are basically just "fixed size data block in, fixed size data block out". You can't overflow a buffer, you can't use-after-free etc, you can't confuse inner protocol serialization semantics with outer protocol serialization semantics, you can't confuse a state machine, you can't have a concurrency bug[1] etc.

C memory safety vulnerabilities arise from trying to handle these dynamic things which rustls fixes.

(Also, there are third party crypto providers implemented in Rust)

[1] from memory safety pov; for side channels rust doesn't have advantages anyway

[gspr]

My point is that the article this thread is attached to starts out with how BoringSSL and AWS-LC won't cut it. And when rustls is suggested as an alternative, it's important to point out that it requires precisely those two (either one of them).

[fulafel]

The article is about TLS. The arguments against those libs don't apply if using them just for the low level crypto algorithms. (Also of course rustls can use other crypto providers besides those)

[gspr]

Then I'm mistaken. Thanks for clarifying.