71–80 of 110 posts
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.
I can't seem to fathom the why in this. Why is Rust different from, say, Python?
Earlier quoted context omitted.
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…
"Constant time" algorithms isn't really about the time it takes. It's more important that they exhibit no observable side effects of a branch. This can be power usage, memory usage as well as time. For instance, a multiply might take slightly more power than an add instruction and that can be monitored. If you think these attacks are unreasonable, recently there was a post on HN about using the LED of a smart card re…
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.
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.
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"?
No - e.g. division is not constant time.
You have to have branchless code and only use certain instructions.
E.g. here is the list for RISC-V.
https://github.com/rvkrypto/riscv-zkt-list/blob/main/zkt-lis...
Most things except div/rem, branches and floating point are ok. Oh and obviously store/load.
Earlier quoted context omitted.
"Constant time" algorithms isn't really about the time it takes. It's more important that they exhibit no observable side effects of a branch. This can be power usage, memory usage as well as time. For instance, a multiply might take slightly more power than an add instruction and that can be monitored. If you think these attacks are unreasonable, recently there was a post on HN about using the LED of a smart card re…
People keep finding serious architectural leaks in CPUs like Spectre/Meltdown, which makes me question whether any constant-time implementation can really be without observable side effects.