[hardwaregeek]

I'd love this to be the case, but ring, which the author of the post created, is unfortunately not really maintained. It doesn't build on Windows ARM, which in turn inhibits rustls. It's a shame because I'd prefer to not depend on OpenSSL. Not that it's the author's fault. We shouldn't be reliant on a single person's contributions to have a working Rust cryptography toolchain.

[olix0r]

That's Brian's point. rustls/webpki/ring do not have funding in line with projects like Go's crypto or BoringSSL:

> ... ARM, Amazon Web Services, Google, and Microsoft [...] should support the Rust community by letting their experts help the Rust community create FIPS-validated cryptography libraries written entirely in safe Rust that expose safe and idiomatic Rust APIs.

Rust's large corporate sponsors need to step up to make these crates more broadly suitable for production.

[pjmlp]

Those corporate sponsors are currently still using C and C++ for this kind of stuff and there is no change in sight.

Alone how much Azure Sphere gets sold as high security device, and the SDK is C only. There is a new preview support for Rust, yet nothing announced for the stable product, only C on that one.

[api]

Last I tried it also had issues with building on platforms like MIPS or PPC. If hardware acceleration is not available it should fall back to software not fail to build.

[duskwuff]

> If hardware acceleration is not available it should fall back to software not fail to build.

It's not always possible to make the same security guarantees for these implementations. Software implementations of AES are frequently vulnerable to cache timing attacks, for example (e.g. [1]); even simple operations integer multiplication may not be constant-time on some architectures.

[1]: https://cr.yp.to/antiforgery/cachetiming-20050414.pdf

[api]

Bit sliced AES is about as good as you can do. ARX ciphers like ChaCha are theoretically better but it’s also not possible to be 100% certain of constant time on every conceivable architecture. And what if the architecture is being emulated? All bets are off then.

At some point this gets pedantic. Just not supporting anything but x64 and ARM64 means any project using ring or a dependency that uses ring can’t build elsewhere which turns ring into a land mine dependency.

[tedunangst]

The problem with making it too easy to fall back is trivial misconfigurations end up using the fall back instead of being corrected.

[api]

Rust had pretty clear architecture conditionals. Not hard to just specify software for architectures without HW acceleration or where it has not been implemented yet.