Stream: git-wasmtime

Topic: wasmtime / issue #5617 Support cryptographic constant-tim...

Wasmtime GitHub notifications bot (Jan 21 2023 at 19:42):

oskgo opened issue #5617:

Feature

Add support for doing cryptographic constant-time in cranelift.

A great introductory guide to cryptographic constant-time can be found at: https://www.chosenplaintext.ca/articles/beginners-guide-constant-time-cryptography.html

Citing the main idea:

Secret information may only be used in an input to an instruction if that input has no impact on what resources will be used and for how long

Benefit

Enables giving higher assurances for cryptographic implementations by allowing them to be secured against or at least resistant to timing attacks.

Implementation

• Adding support for annotating "secret" values/identifiers
• Restricting optimizations and codegen involving these secrets

Caveats

• Performance is very important for cryptography, so the level of interest depends on whether it is possible to get comparable performance with Cranelift. This is not about how good Cranelift optimizes, but how well hand-optimized code that ends up in Cranelift can run in the best case.
• It is unlikely for cryptography to be written in cranelift IR itself, so the benefits of this proposal are unlikely to bear fruit until WASM or Rust get support.

Wasmtime GitHub notifications bot (Jan 21 2023 at 20:39):

bjorn3 commented on issue #5617:

It is unlikely for cryptography to be written in cranelift IR itself, so the benefits of this proposal are unlikely to bear fruit until WASM or Rust get support.

I guess fiat-crypto could get a Cranelift backend. That would give you a lot of elliptic curve implementations without too much effort. Still leaves other kinds of crypto primitives though.

Wasmtime GitHub notifications bot (Jan 21 2023 at 20:50):

oskgo commented on issue #5617:

Yes, and there are others that could get Cranelift back-ends that would then immediately benefit as well.

I guess my point is more that this proposal won't do much by itself and has to rely on what other projects do to get benefits.

Sadly this argument can be made by both sides. Someone has to take the first step.

Wasmtime GitHub notifications bot (Jan 23 2023 at 20:20):

jameysharp commented on issue #5617:

I wonder if adding this infrastructure might allow us to remove the select_spectre_guard variant of the select instruction? I'm imagining something like tagging the result of a bounds-check as "secret" before passing it to select.

If constant-time operations can be a special case of the kind of optimization barrier we already need for Spectre mitigations, I think that would make it easier to justify maintaining this infrastructure before anybody else starts using it.

Wasmtime GitHub notifications bot (Jan 24 2023 at 00:37):

oskgo commented on issue #5617:

You couldn't remove the variant by making the select condition a secret without changing the abstract semantics. select_spectre_guard has sideffects, while select doesn't, so IIUC the optimizer is free to remove calls to select very freely, while calls to select_spectre_guard can only be removed when an entire branch is removed.

If select_spectre_guard having sideeffects is just a hack to prevent it being replaced with branches, then using a secret condition on select instead would actually be an improvement since it would allow deleting the instruction when it isn't needed. This also makes more sense, since conditional moves don't really have side effects, it's just the alternatives that might have them.

Wasmtime GitHub notifications bot (Jan 24 2023 at 01:17):

cfallin commented on issue #5617:

If select_spectre_guard having sideeffects is just a hack to prevent it being replaced with branches

Indeed it is a hack; the only restriction that's necessary is that it remains a cmove and is neither converted to a branchy form, nor is constant-propagated. (Well, I suppose cprop based on a statically constant value would preserve the speculation safety, but cprop from a path-sensitive constant past a branch would not.)

I very much like @jameysharp 's idea of subsuming this with a more general taintedness notion that ensures no branch depends on it!

Last updated: Nov 22 2024 at 17:03 UTC