[julian-klode]

Actual cryptography code, the best path is formally verified implementations of the crypto algorithms; with parsers for wrapper formats like OpenPGP or PKCS#7 implemented in a memory safe language.

You don't want the core cryptography implemented in Rust for Rust's sake when there's a formally verified Assembler version next to it. Formally verified _always_ beats anything else.

[jcranmer]

I should have clarified that I was primarily referring to the stuff dealing with all the wrapper formats (like PKIX certificate verification), not the core cryptographic algorithms themselves.

The core cryptographic algorithms, IMHO, should be written in a dedicated language for writing cryptographic algorithms so that they can get formally-verified constant-time assembly out of it without having to complain to us compiler writers that we keep figuring out how to deobfuscate their branches.

[oofbey]

Sure. But assembly implementations by definition are not portable. And I don’t know what it takes to write a formally verified library line this, but I bet it’s very expensive.

In contrast, a rust implementation can be compiled into many architectures easily, and use intrinsically safer than a C version.

Plus cryptography and PKI is constantly evolving. So it can’t benefit from the decades old trusted implementations.

[kelnos]

> Formally verified _always_ beats anything else.

Formally verified in an obscure language where it's difficult to find maintainers does not beat something written in a more "popular" language, even if it hasn't been formally verified (yet?).

And these days I would (unfortunately) consider assembly as an "obscure language".

(At any rate, I assume Rust versions of cryptographic primitives will still have some inline assembly to optimize for different platforms, or, at the very least, make use of compile intrinsics, which are safer than assembly, but still not fully safe.)

[steveklabnik]

With crypto, you really want to just write the assembly, due to timing issues that higher level languages simply cannot guarantee.