If you don’t care about prolific side-channels... and mountains of extra complexity and attack surface.
-
-
-
People are doing it. And people are switching crypto libraries from ones that try hard to avoid side channels to ones that support WebAssembly.
-
It would be great to have a synchronous WebCrypto API so that cross-platform libraries can use it to implement their synchronous APIs, instead of having to choose between not supporting WebAssembly and supporting it in a dangerous way.
-
I believe the old WebCrypto editor is working on other things, but a synchronous, worker-only interface sounds totally plausible. Create a WICG repo for it?
-
It was something explored but
@slightlylate was highly skeptical of due to things like scheduling and shared workers. Certainly the blink infra doesn’t exist as of last year, when we last (again) explores -
The design was made so that the promises could be synchronously resolved and async/await would handle any other grossness
-
C programs, Rust programs, etc. don't use async/await. They use sync APIs.
-
Async APIs offer suspect functionality on top of sync API’s that do not leak information. I find the vast majority of developers who think they understand async APIs do not, thus the implementation complexity forced by their design is not worth it.
- 1 more reply
New conversation -
-
-
WebCrypto being async drove me insane while implementing the TypeScript version of Miscreant. If it weren't for async/await I think I wouldn't have even bothered.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
that's actually hilarious hahaha
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.