7 comments

[ 3.9 ms ] story [ 29.6 ms ] thread
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.

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.)

Definitely. I wasn't aware about constant time constraints at the time.