AWS Libcrypto for Rust | Hacker News Reader

AWS Libcrypto for Rust

github.com

91 pointsjrpelkonen26 comments

Open articleView on HN

How crazy is the build chain these days? Well, to build it in FIPS mode you need a Go compiler!

Go is only needed to build the test suite.

/I asked the same question and got this from the dev.

It's just a wrapper arround aws-lc which is 100% C++/C/ASM.

It still matters for the ecosystem to have SDKs available for use

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.

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.

There's also dfdx, which is pure Rust and really leverages the type system.

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!

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.

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].

[1] https://www.memorysafety.org/blog/rustls-performance/

> 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.

What kind of improvement are you looking for? A `blackbox` intrinsic with stronger guarantees?

So what?

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.

So what? why don’t you make a wrapper? Or if you don’t like that way, make one yourself instead of complaining thing’s others give you for free?

> aws-lc-rs is a cryptographic library using AWS-LC for its cryptographic operations.

Why should I use AWS-LC over the myriad cryptography libraries out there already?

I would wager this is a big reason:

> 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.

Exactly, see the "Motivation" section of the README

Another nice reason is that AWS-LC includes rewrites and optimizations that make it faster than alternatives, especially on Graviton.

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.

> see this issue filed by Josh Triplett

Check who you are replying to ;)

Blog post with performance chart: https://aws.amazon.com/blogs/security/aws-lc-is-now-fips-140...

There's also an open issue in Boring (the crate for BoringSSL) to enforce usage of FIPS https://github.com/cloudflare/boring/issues/182

Joy!

Reply on news.ycombinator.com