Till Schneidereit (Aug 19 2025 at 10:42): Till Schneidereit (Aug 19 2025 at 10:42):Similar question to the one Lann raised in #wasm > ✔ constant time equality: do the security notes on the aes_gcm crate apply to Wasm such that the implementation can be expected to be constant-time? My reading of the security audit (the link in the crate docs isn't working anymore) that was done on the implementation in 2019 is that the answer might be yes? @Chris Fallin this seems like a topic you'd have opinions on :slight_smile:
Lann Martin (Aug 19 2025 at 12:19):using a portable implementation which is only constant time on processors which implement constant-time multiplication.
The Wasm spec afaik makes no guarantees but in practice I'd be very surprised if any runtimes themselves triggered data dependent timing for multiplies.
Chris Fallin (Aug 19 2025 at 17:06):If we're looking for an auditable chain of specified guarantees, then of course Wasm doesn't give us anything, but as for what to actually expect: for truly data-dependent (i.e., not constant-propagated) ALU operations, we tend to lower them to the equivalent CPU instructions more or less directly, so we "pass through" whatever requirements (downward) or guarantees (upward) re: constant time might apply. This is certainly the case for multiplication -- a plain integer multiply with two non-constant inputs should always lower to a plain integer multiply CPU instruction, so then you'd need to rely on whatever the ISA spec says and/or what the implementation does, depending on what level of guarantee you're looking for.
On Intel and AMD implementations of x86 at least the integer multiplier has a fast fixed-latency pipeline, i.e. latency won't depend on the data. Note this isn't a guarantee but it'd be exceptionally weird for a new high-performance core design to change this.
It'd still be nice to formalize all this with a "constant-time Wasm" spec, but that's a boulder for someone else to roll uphill :-)
Till Schneidereit (Aug 19 2025 at 17:51):Thank you, that all matches my understanding. I guess basically, "if a security audit says that code is fine when compiled to a mainstream platform via LLVM, then it'll be fine running in wasmtime on the same platform, too"?
Till Schneidereit (Aug 19 2025 at 17:54):and yes, constant-time wasm would be awfully nice to have. @Dan Gohman and I talked about this at the CG f2f in Pittsburgh; one key observation is that the ct-wasm proposal does a lot more than what's truly needed in make constant-time-ness a type system concern. To be able to port existing code to target wasm with actual "guarantees" (as far as those go on the target hardware, anyway), we'd only need the actual operations. That seems like it could conceivably be a much smaller lift
Chris Fallin (Aug 19 2025 at 17:58):"if a security audit says that code is fine when compiled to a mainstream platform via LLVM, then it'll be fine running in wasmtime on the same platform, too"?
Informally and without an official crypto rubber stamp, but "for real people in the real world with real thinking rocks", yep, that sounds right!
Till Schneidereit (Aug 19 2025 at 17:59):oh yeah, I definitely wasn't looking for more than the informal version!
Last updated: Dec 06 2025 at 05:03 UTC