For what it’s worth, I think async crypto is not the right choice in JS, for the same reason why it’s not the right choice in any other language.
-
-
I guess a good rule of thumb is “if it blocks your CPU core, it’s not async”? That principle would make I/O and WebGL async but crypto (AES-NI) sync.
1 reply 0 retweets 5 likes -
Blocking the CPU core doesn't mean it needs to block rendering, but when we give main-thread JS sync APIs, that's what folks do. I guess another point in the design space would be to make crypto worker-only?
2 replies 0 retweets 1 like -
OMT layout sure would be nice (if it’s web compatible) ;) Anyway, how slow are we talking about anyway? AES-NI is really fast.
0 replies 0 retweets 1 like -
Replying to @BRIAN_____ @jyasskin and
In practice, if you’re going to make me have to use a promise to, say, decrypt 1kB of data using AES, I’m just going to use a wasm implementation of AES instead of turning my code into callback soup.
4 replies 0 retweets 8 likes -
Replying to @pcwalton @BRIAN_____ and
Having done both, I'm also leaning towards WASM at this point. For the algorithms I'm implementing I think they will be faster than the WebCrypto-based equivalents, with a friendlier API.
1 reply 0 retweets 0 likes -
Right. That's the cost of getting WebCrypto wrong. People will, understandably, do that. Now we have larger download, a slower (ignoring WebCrypto overhead and algorithm selection) and less side-channel-protected impl, AND, in so far as this was misuse, we didn't even avoid it!
2 replies 0 retweets 1 like
Note that this is what happened with Web Audio. I’m very wary of overengineering specs these days.
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.