On "constant time" about noble-bls12-381 HOT 2 CLOSED

Constant-time operations is a battle between developer and compiler. Developer wants slow but constant time code, compiler aims to produce the fastest possible code.

With JIT we don't have any control over what code will run, since JIT can easily optimize away
constant-time operations. Or, JIT can use any machine instruction / code which will have timing variation depending on secret value.

For compiled languages we can verify compiler output and make sure that code is actually
constant-time. BTW, this is very hard: even memory access patterns can easily make code non-constant time because of CPU caches.

For JS there is no such option. Suppose you wrote constant-time code and verified that it is indeed CT within all JS engines with all use-cases. It can easily change with next update of browser/JS engine. WASM can use JIT too.

As for GC: it makes timing attacks harder. On the other hand, it can expose some information about secret value, but it will be very hard to restore the secret from it. At the same time, restoring secret values from bigint operation in EC is hard too.

So, how bad it actually is for JS? If you expose any api that depends on privateKey,
like uncached access to getPublicKey or you're creating signature with enough speed to uncover timing variances, there can be a problem.

However, just caching getPublicKey (for example at start of application) or asking user confirmation for transaction signing (in web wallets) could make it safe enough.

from noble-bls12-381.

Constant-time operations is a battle between developer and compiler.

Correct. And my point is that JIT and Garbage Collection are not a part of the equation. Because the struggle is the same in either case. It's not JIT or GC that makes pure JS [or something else!] unsuitable as a secure platform.

As for "something else" in the previous paragraph. Speaking of Webasm. Question is not whether or not it JITs, or when JS makes a call, or even how long it takes each time. [Again, it's not about wall-clock time.] Question is if there is a contract that VM is supposed to uphold that facilitates constant-time execution. Well, this doesn't resolve the conflict between developer and high-level language compiler, but that's not the current point.

As for "a contract to uphold." Well, I'm not that much into Wasm spirit, but spec does talk about instruction execution determinism. Which suggests that VM is obliged to execute instructions in provided order and is not free to perform certain optimizations. Most notably those that would reorder or omit loads and stores [from/to main memory]. And judging from what I've observed so far it is the case. Customarily this would do. Not saying that it actually does though, or that it will in perpetuity.

from noble-bls12-381.