Earlier quoted context omitted.
Rust has simd support, so maybe the latter is the issue.
not in stable yet
core::arch::x86_64::_mm256_shuffle_epi8 and such seem to be in stable.
Rust Cryptography Should Be Written in Rust
41–50 of 110 posts
Re: Rust Cryptography Should Be Written in Rust
#42So 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?
Linkerd's sidecar proxy (https://github.com/linkerd/linkerd2-proxy) is implemented in Rust. It implements transparent mTLS, HTTP load balancing, telemetry, etc. Rust gives us safety and security with a minimal resource footprint.
Re: Rust Cryptography Should Be Written in Rust
#43I'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.
That's Brian's point. rustls/webpki/ring do not have funding in line with projects like Go's crypto or BoringSSL:
> ... ARM, Amazon Web Services, Google, and Microsoft [...] should support the Rust community by letting their experts help the Rust community create FIPS-validated cryptography libraries written entirely in safe Rust that expose safe and idiomatic Rust APIs.
Rust's large corporate sponsors need to step up to make these crates more broadly suitable for production.
Re: Rust Cryptography Should Be Written in Rust
#44Related is this effort to write a PGP backend in Rust : https://sequoia-pgp.org/
Re: Rust Cryptography Should Be Written in Rust
#45So 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.
I am talking about building nodes that execute the underlying consensus protocols. Not the front end client side applications.
Re: Rust Cryptography Should Be Written in Rust
#46Re: Rust Cryptography Should Be Written in Rust
#47Earlier 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 subtlety is that eliminating branching isn't sufficient to have constant time code. A simple example is using trigonometric and transcendental opcodes. They don't branch (at the assembly level), but on x86 take variable amounts of time depending on the input operand. Very few algorithms actually use these opcodes though, so a more relevant concern is memory access due to variable latency. Even if you have that nailed down, integer operations like multiplication and especially division can take variable amounts of time depending on the input.
Writing truly constant time code on modern processors ranges is difficult at best, and usually less efficient than variable-time code.
Re: Rust Cryptography Should Be Written in Rust
#48Earlier quoted context omitted.
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.
Timing attacks are common everywhere, by the way. Simplest example, perhaps a bit too contrived:
I'm an attacker doing targeted research. I want to see if a multi-auth system has an association between two email addresses tied to the same account.
Pulling a database record or in-memory record (e.g. via LFU/LRU cache) in some cases may cache the account record, which means a subsequent record might be warm when fetched with the second email.
I run a time analysis against the endpoint with garbage addresses, known addresses (that I've set up) and the two target addresses to check subsequent fetch speeds.
In some cases, this will cause enough of a time difference to tell me if there's a connection.
Timing attacks are hard, and even a well-architected system can expose information indirectly. Encryption is a bit one if the inputs are static (e.g. keys or the like) and are a common way to target endpoints.
Re: Rust Cryptography Should Be Written in Rust
#49So 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?
Yes, in fact I see hardly any cryptocurrency stuff with rust.
I'm building an OS in rust, and write most firmware with rust too.
Re: Rust Cryptography Should Be Written in Rust
#50I reckon https://github.com/RustCrypto is an effort in this space.
I thought it weird that the post didn’t mention RustCrypto. It’s legit.