Rustls still outsources cryptographic primitives. I believe the currently supported providers of those are… drumroll… AWS-LC and Ring. The latter is a fork of BoringSSL. The article describes AWS-LC and BoringSSL as "Googled and Amazoned to death; they don't care about anyone but their own use cases".

The state of things sucks :-(

▲

fulafel 4 hours ago | parent [-]

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 2 hours ago | parent [-]

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 2 hours ago \| parent [-]
		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)