Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation. Furthermore, it has a ring compatible API, and it is evidently faster than ring itself[1].
> Maybe so, but pretty much all cryptographic primitives have to be written in assembly anyway to achieve constant time operation.
This really oversimplifies the situation. Even at my most pessimistic, I believe just a very few, very small, parts need to be written in assembly language to maintain the "constant time" properties, and that's just until we can work together better with the Rust language team to eliminate these small gaps. Even before then, the Rust language team is doing a good job at independently improving and expanding the building blocks we need to get to entirely-safe (in the Rust `unsafe` sense) and high-performance crypto libraries in Rust.
> evidently faster than ring itself[1].
If you're running on an AVX-512 system, there is a notable performance gap, temporarily. This state will persist for a few months at most, most likely. It's inevitable that we (all the OpenSSL forks, and even including non-OpenSSL-forks like rust-crypto) all converge on more-or-less the same implementations and/or different implementations of the same optimizations.
It's incredible how many Rust packages are just wrappers around C++ implementations. That being said, as a weekend rustacean (I hate saying it but couldn't resist the urge) and current user of tch-rs (a rust PyTorch C++ wrapper) I'm glad somebody out there is writing the interfaces to allow more functionality in Rust. It's probably a good thing that C++ is so established since it allows these types of packages to come to fruition without the leg work of an actual re-implementation of the same logic in Rust from scratch.
It seems odd but it makes sense, right? Rust prevents a whole class of bugs. But, reusing existing code that’s already well debugged and battle-tested prevents even more bugs!
Have you looked at burn.dev? It’s kind of a neat approach where they backend to torch/candle/other things and are also building a pure Rust backend that compiles to webgpu shaders.
I think it's actually surprising how few crates are C++ wrappers. You can really tell if you try and cross-compile big Rust programs because it's always the C/C++ wrapper crates that cause issues and 90% of the time it's OpenSSL.
There are more wrappers than in Go, but probably fewer than Python.
It allows Rust code to access a set of fast and battle-tested implementations. I personally don't care about the tools and languages something uses as long as it does a good job.
> This crate provides bindings to AWS-LC-FIPS 2.x, which has completed FIPS validation testing by an accredited lab and has been submitted to NIST for certification.
If you are in a regulated environment, that’s reason enough.
Are there benches on this vs say OpenSSL on Graviton and Apple M chips? I would be curious how big the difference is vs whatever NEON optimizations are in OpenSSL (and friends) already.
One reason: you can use this as a backend to rustls, and then you no longer have anything under the OpenSSL license in your dependencies, which improves the license compatibility of your project.
Again, this is just a temporary situation, and a matter of burning down a list of small tasks. Not that the OpenSSL license issue is a big deal for most anyway. Feel free to help; see this issue filed by Josh Triplett: https://github.com/briansmith/ring/issues/1318#issuecomment-...
Yeah, I realize, and I am looking forward to having multiple options to choose from that all have the same license compatibility. It's nice that there's a short-term solution that's available for people who need to ship things soon, and it's nice that there's a longstanding library (ring) that'll long-term will be capable of providing a compatible solution as well.
