Live data from Hacker News

Rust Cryptography Should Be Written in Rust

briansmith.org

81–90 of 110 posts

Re: Rust Cryptography Should Be Written in Rust

#81
post #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.

> 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

Re: Rust Cryptography Should Be Written in Rust

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

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

But that's basically anything that touches the internet.

Not having buffer overflow vulnerabilities in your communications code is huge.

Re: Rust Cryptography Should Be Written in Rust

#84
post #59
post #3

Earlier quoted context omitted.

> So far the only solid use case for Rust that I have seen in applications where security is extremely important. Playing devil's advocate, when is security not extremely important, except maybe in throwaway bash script-type applications?

Games. The attack surface for third-party input is very limited, and you can just secure those bits rather than adopting a new language for the entire program. Like, you need to be able to sandbox mods if they're a thing, and Rust's memory safety only handles a tiny part of that.

Multiplayer games have huge attack surfaces.

Re: Rust Cryptography Should Be Written in Rust

#85
post #38

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

FWIW, RustCrypto is neither written in safe rust or only rust. It uses inline assembly, unsafe byte manipulation, and unsafe intrinsics

> unsafe intrinsics

You mean like AESENC which you should always be using if available?

The rust fanclub obsession with calling things like that unsafe simply because it has the same keyword in front of it is fairly ridiculous.

> inline assembly

Sometimes it's the only way to get some sort of constant time guarantees.

Re: Rust Cryptography Should Be Written in Rust

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

Re: Rust Cryptography Should Be Written in Rust

#87

Earlier quoted context omitted.

Deterministic builds, and inability to ensure constant-time operations are the two that come to mind. The first is a build security / supply chain issue, and the latter is a real vulnerability if the rust compiler "helpfully" optimizes away no-op operations in alternate code paths.

Whenever I'm wearing my tinfoil hat, I wonder if all the advice to never implement your own crypto is a conspiracy to reduce independent implementations of cryptography algorithms. I know constant time operation is important for these algorithms, but couldn't I do this with a timer? Call the algorithm, store the result, return the result exactly one second (an eternity in CPU time) after it was called. Basically put…

No. Timing attacks look at statistical distributions given a set of inputs. Adding a flat 1 to all the times does not flatten the distributions. Likewise, adding a random jitter has the same problem, where it increases the variance but doesn't remove it - you need more samples to get the same confidence interval, which is very different from preventing timing attacks entirely.

Re: Rust Cryptography Should Be Written in Rust

#88
post #76
post #75

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 feel like yes the basic crypto functions should be hardware, hopefully done right and those exposed in the language as builtin functions. Not compiled at the whim of the compiler. Although will point out hardware guys have been mucking up and creating security holes too.

That would make holes in the core unfixable.

Re: Rust Cryptography Should Be Written in Rust

#89

Earlier quoted context omitted.

Deterministic builds, and inability to ensure constant-time operations are the two that come to mind. The first is a build security / supply chain issue, and the latter is a real vulnerability if the rust compiler "helpfully" optimizes away no-op operations in alternate code paths.

Whenever I'm wearing my tinfoil hat, I wonder if all the advice to never implement your own crypto is a conspiracy to reduce independent implementations of cryptography algorithms. I know constant time operation is important for these algorithms, but couldn't I do this with a timer? Call the algorithm, store the result, return the result exactly one second (an eternity in CPU time) after it was called. Basically put…

All that will do is slow an attacker down by a very small amount, it doesn't change the basic nature of the attack at all, if it worked before it will still work, just slightly slower. It's like adding a little bit of noise to a signal.

Re: Rust Cryptography Should Be Written in Rust

#90
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've used Rust for years in embedded Linux devices and more recently in signal processing.
Post reply on HN