I'm a security noob, but side channel attacks seem to me like something that you fundamentally just can't address by writing better software in a high-level language. The entire point is that they dig underneath all of your abstractions. It doesn't seem particularly tenable to keep playing whack-a-mole in this way.
You can write algorithms that leak every bit of your secrets, trivially. The npm "elliptic" package does this. Daniel Bleichenbacher has tested several packages' timing leakage in Rooterberg that are easily exploited: https://github.com/bleichenbacher-daniel/Rooterberg/blob/mai...
You can use algorithm implementations that do not have secret-dependent timing differences in any language, as long as you are clear that your guarantees do not extend to the underlying runtime or to compiler optimizations. This isn't perfect, but it's better.
You can go further Rust-to-WASM and use tools like https://github.com/trailofbits/skills/tree/main/plugins/cons... to check the assembly and the runtime that the assembly runs in. (Most of the linked Claude skill is a Python program. It just relies on AI to eliminate false positives.)
Read the whole thing, but OK you didn't accuse anyone of being evil yet. But let me clarify that even if a later optimization breaks your constant time property that still wouldn't be evil.
You walked back putting an accusation of evil in my mouth while following up with warning me not to make an accusation I would not make to begin with. Incredible.
I was working on reimplementing the WebRTC stack in JavaScript a long time ago, never finished. The crypto folks at Mozilla (ekr@) suggested "maybe don't do that for dTLS."
I'm a security noob, but side channel attacks seem to me like something that you fundamentally just can't address by writing better software in a high-level language. The entire point is that they dig underneath all of your abstractions. It doesn't seem particularly tenable to keep playing whack-a-mole in this way.
You can write algorithms that leak every bit of your secrets, trivially. The npm "elliptic" package does this. Daniel Bleichenbacher has tested several packages' timing leakage in Rooterberg that are easily exploited: https://github.com/bleichenbacher-daniel/Rooterberg/blob/mai...
You can use algorithm implementations that do not have secret-dependent timing differences in any language, as long as you are clear that your guarantees do not extend to the underlying runtime or to compiler optimizations. This isn't perfect, but it's better.
You can go further Rust-to-WASM and use tools like https://github.com/trailofbits/skills/tree/main/plugins/cons... to check the assembly and the runtime that the assembly runs in. (Most of the linked Claude skill is a Python program. It just relies on AI to eliminate false positives.)
The real question is: What's your threat model?
Nobody was evil you just tried to rely on a property that V8 never promised.
Wasm doesn't promise it either but there's a much better chance you get what you want there.
> Nobody was evil you just tried to rely on a property that V8 never promised.
Tell me you didn't read past the headline without telling me you didn't read past the headline.
Read the whole thing, but OK you didn't accuse anyone of being evil yet. But let me clarify that even if a later optimization breaks your constant time property that still wouldn't be evil.
You walked back putting an accusation of evil in my mouth while following up with warning me not to make an accusation I would not make to begin with. Incredible.
I don't know if you are the author but he wrote:
The only things that can easily go wrong now are:
The compiler turns out to be evil and introduces an “optimization” that I don’t anticipate
The V8 developers turn out to be evil and modify how this logic works and break my assumptions in a future release
Ah, right. That was clearly tongue-in-cheek and easily forgettable, not an actual accusation on either party.
I was working on reimplementing the WebRTC stack in JavaScript a long time ago, never finished. The crypto folks at Mozilla (ekr@) suggested "maybe don't do that for dTLS."
I mean this with absolutely no shade but: That was objectively good advice.
(Not to detract from anyone's cleverness or hard work.)