Live data from Hacker News

Rust Cryptography Should Be Written in Rust

briansmith.org

21–30 of 110 posts

Re: Rust Cryptography Should Be Written in Rust

#21

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?

Probably SIMD support and constant time support. Crypto libraries tend to use SIMD a lot to be fast.

You can write constant time code in Rust by carefully making sure your code only compiles to constant time instructions without branches, but you'd really want some kind of annotation on the code to enforce that.

That's mostly a guess though.

Re: Rust Cryptography Should Be Written in Rust

#22
post #2

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?

I'm building a 2D simulation game compiled to WASM using Bevy!

It's nicer writing in Rust than JS, no GC makes Rust a good WASM candidate, theoretically the performance can be better if you're careful, people take 2D game engines more seriously in lower level languages, and it keeps the door open for shipping on Steam later.

I've found it much slower to develop in, though. Compilation times are an issue and after working in JS for decades I realize how big the JS ecosystem is compared to something like Rust.

I doubt the decision was a good choice overall in terms of trying to ship an MVP, but it might still pay dividends for a finished product, if the game gets there, due to having a higher cap on performance

Re: Rust Cryptography Should Be Written in Rust

#23
post #2

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?

For our client, we've developed a desktop application in Rust – with a thin GUI frontend in C++/Qt – to filter, process, and visualize sensor data streams (3D point cloud data from a Lidar). Each data stream was about 400-500 Mbit/s in 55k UDP packets per second, with support for at least 4 simultaneous streams. The focus was on high performance and development speed, security didn't matter at all.

We chose Rust for its unique position in the performance/productivity tradeoff space, and didn't regret it even for a second. There's no way we could have pulled this off with C++ in the same time, especially the bug-free parallelization.

Re: Rust Cryptography Should Be Written in Rust

#24
post #5

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

ISAs regularly leave all kinds of behavior undefined when they think it doesn’t matter (such as the state of the arithmetic flags after operations that shouldn’t need to the tested).

(But this is also irrelevant: assembly can be completely wrong and exploitable while also being perfectly well defined.)

Re: Rust Cryptography Should Be Written in Rust

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

Re: Rust Cryptography Should Be Written in Rust

#27

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?

Probably SIMD support and constant time support. Crypto libraries tend to use SIMD a lot to be fast. You can write constant time code in Rust by carefully making sure your code only compiles to constant time instructions without branches, but you'd really want some kind of annotation on the code to enforce that. That's mostly a guess though.

isnt constant time orthogonal to whether there are branches?

Re: Rust Cryptography Should Be Written in Rust

#28
post #2

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 is just a nice general purpose language. It's good more or less everywhere.

There are a few places where I wouldn't recommend it - for beginners, when compile time is really important (e.g. as a scripting engine in games), or where you need a repl (science).

But otherwise it's a better choice than most languages for most tasks.

Re: Rust Cryptography Should Be Written in Rust

#29

Earlier quoted context omitted.

Probably SIMD support and constant time support. Crypto libraries tend to use SIMD a lot to be fast. You can write constant time code in Rust by carefully making sure your code only compiles to constant time instructions without branches, but you'd really want some kind of annotation on the code to enforce that. That's mostly a guess though.

isnt constant time orthogonal to whether there are branches?

No. Constant wall clock time involves not using branches. Maybe you're thinking of "asymptotic constant time" or "runtime bounded above by a constant." These are not what is needed, because what is needed is to not expose any information via timing.

Re: Rust Cryptography Should Be Written in Rust

#30

Earlier quoted context omitted.

Probably SIMD support and constant time support. Crypto libraries tend to use SIMD a lot to be fast. You can write constant time code in Rust by carefully making sure your code only compiles to constant time instructions without branches, but you'd really want some kind of annotation on the code to enforce that. That's mostly a guess though.

isnt constant time orthogonal to whether there are branches?

Because branch prediction exists: sometimes yes, often no. Among other reasons.
Post reply on HN