Live data from Hacker News

Rust Cryptography Should Be Written in Rust

briansmith.org

31–40 of 110 posts

Re: Rust Cryptography Should Be Written in Rust

#31
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?

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

I work at Materialize which is building database software in Rust. One of my coworkers blogged about our experience with the language here: https://materialize.com/blog/our-experience-with-rust/

Re: Rust Cryptography Should Be Written in Rust

#32
post #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…

Why use C++ for the front-end though?

Re: Rust Cryptography Should Be Written in Rust

#33

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.

Rust has simd support, so maybe the latter is the issue.

Re: Rust Cryptography Should Be Written in Rust

#34

Earlier quoted context omitted.

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.

What if there are branches but both paths result in the same number of cycles being required to execute the instructions?

Is it correct to say: "all branchless code runs in constant time, but not all constant time code is branchless"?

Re: Rust Cryptography Should Be Written in Rust

#35
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?

Defect language in the blockchain space is still JS/TS. Not sure you should be relying on their signals for security assurances.

Re: Rust Cryptography Should Be Written in Rust

#36

Earlier quoted context omitted.

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.

What if there are branches but both paths result in the same number of cycles being required to execute the instructions? Is it correct to say: "all branchless code runs in constant time, but not all constant time code is branchless"?

Because of speculative execution, branchy code with equal-runtime branches will still take different amounts of time if it is called repeatedly, usually in ways that reveal information about the input.

Re: Rust Cryptography Should Be Written in Rust

#37

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.

Rust has simd support, so maybe the latter is the issue.

not in stable yet

Re: Rust Cryptography Should Be Written in Rust

#39

Earlier quoted context omitted.

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.

What if there are branches but both paths result in the same number of cycles being required to execute the instructions? Is it correct to say: "all branchless code runs in constant time, but not all constant time code is branchless"?

The issue is speculative execution. Whenever there is a branch, the CPU makes a guess. If it guesses wrong, it has to go back to the correct path which introduces a delay. So any branching code has the possibility of revealing information through the branch predictor.

Re: Rust Cryptography Should Be Written in Rust

#40

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.

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.
Post reply on HN