The second comment on the page sums up what I was going to point out:
I’d be careful making assumptions like this ; the same was true of exploits like Spectre until people managed to get it efficiently running in Javascript in a browser (which did not take very long after the spectre paper was released). Don’t assume that because the initial PoC is time consuming and requires a bunch of access that it won’t be refined into something much less demanding in short order.
Let’s not panic, but let’s not get complacent, either.
This requires local access to do and presently an hour or two of uninterrupted processing time on the same cpu as the encryption algorithm.
So if you’re like me, using an M-chip based device, you don’t currently have to worry about this, and may never have to.
On the other hand, the thing you have to worry about has not been patched out of nearly any algorithm:
https://xkcd.com/538/
Sure. Unless law enforcement takes it, in which case they have all the time in the world.
Yup, but they’re probably as likely to beat you up to get your passwords.
The second comment on the page sums up what I was going to point out:
Let’s not panic, but let’s not get complacent, either.
I mean, unpatchable vulnerability. Complacent, uncomplacent, I’m not real sure they look different.
Can’t fix the vulnerability, but can mitigate by preventing other code from exploiting the vulnerability in a useful way.
That’s the sentiment I was going for.
There’s reason to care about this but it’s not presently a big deal.