The primitives aren't a problem. You can't write them in any vaguely modern high level language. And when I say "High level" I mean that the way K&R does when they describe their new C programming language as high level. The reason you can't write cryptographic primitives in a high level language is that optimising compilers love clever tricks which offer data dependent performance, across every layer of their design - but in cryptography we want constant execution time regardless of either the plaintext or keys used.

The problem with OpenSSL isn't these cryptographic primitives, that's why you will see basically the same primitives re-used in lots of different places. It's like finding out that the guy who was just arrested for murder also eats pizza. Yeah, people do that. The problem wasn't the pizza, it was the murder. OpenSSL's implementation of the AES cipher isn't broken, the problem is elsewhere.

You might like https://github.com/ctz/graviola/

Also, even if rustls is using aws-lc-rs, you still get the TLS parts from the rustls project, and aws-lc-rs is just lower-level crypto. That means there's less places for Amazon to say no; they either implement an algorithm or don't.

The author also doesn't specify what that even means and what problems it causes

there is https://github.com/RustCrypto/rustls-rustcrypto fwiw

It's a great effort, but it's far from usable:

> USE THIS AT YOUR OWN RISK! DO NOT USE THIS IN PRODUCTION

What? Ring is not even close to a fork of BoringSSL; it merely borrows subroutines from BoringSSL.

Ok, maybe not a fork outright. But the project description says: Most of the C and assembly language code in ring comes from BoringSSL.

That's the proper way to use OpenSSL and derivatives. Their C and assembly code for crypto primatives is good.

Protocol code and x.509 certficate handling will probably be better written in another language.