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.

The problem is wanting both fast and constant-time. That's so machine level that it is hard to even talk about in a high level language.

On the other hand, most of the security problems found in OpenSSL are not in the core cryptographic functions. They're in the networking and certificate management machinery. All that should definitely be in Rust.

I reckon https://github.com/RustCrypto is an effort in this space.

What are the language/tooling gaps specifically that prevent this today, and have there been RFCs to close them? Are the gaps primarily "in-language" or missing tooling for formal verification?

Related is this effort to write a PGP backend in Rust : https://sequoia-pgp.org/

So far the only solid use case for Rust that I have seen in applications where security is extremely important.

Not wonder it is becoming the de-facto language for building applications in the blockchain space.

Does anyone else use Rust outside the blockchain/cryptography space? What are you working on?

> Rust should be improved to provide the necessary building blocks that are needed to write cryptography code that is free from timing side channels and similar hazards

I misread that at first as saying it already did and was rushing to the comments to say "like hell it does!"-- but this is a difficult situation given that it doesn't really even exist in C where it would be easier to provide.

Technically, since Intel and AMD won't make guarantees that operations like multiplies won't have data dependent timing no language on these popular systems provide what is needed, at least in theory. (In practice things are somewhat better).

Ignoring the processor interface issues, it would be totally rad if there were types in rust for secrets that were guaranteed to get suitable handling. But doing so would probably require architectural changes to LLVM...

Nope. Cryptography code should be written using proof assistents. Proving the correctness of the code.

Like the Everest project.

I like the part where he says companies should spend money to give him something that'll be less secure (because it'll be a redundant implementation) to satisfy an aesthetic request.

Forget the naysayers, I for one pray that the crypto graybeards will learn rust and grant the author his wish.

I can't seem to fathom the why in this. Why is Rust different from, say, Python?

Security is a weak-link problem. Once you decide to solve the bootstrapping challenge, you can use Rust for everything else.

But which version of rust?

Crypto code should be written in assembly. Zero ambiguity, zero undefined behavior, 100% verifiable.