Remote Spectre exploits demonstrated

> without code being involved

When you perform a network request you cause code to be executed. The code on the server is designed to respond to the request, in the same way as any local cross-process call responds to a request (including a kernel system call).

The key difference is not in the trigger, but in the measurement: measuring cache timing effects is more tricky when you can only interact with the target machine via a relatively high latency (and highly variable latency) channel such as the network. The new attack here shows how this can still be done probabilistically.

If you wonder how you can flush the cache over the network (without code involved) the answer is the same ad the answer to this question: why can't spectre be solved by just restricting the ability to issue a cache flush instruction? You can effectively flush the cache by performing more requests that cause other stuff to be loaded in the cache and evicting the parts you want to be evicted.

This kind of attack is catastrophic in cryptography.

It can go up to 125 bytes per second, maybe more. I've not finished reading the pdf yet

Attacks only get better over time. In a sense, there are security flaws in every computer program, which only get clearer with time. The issue here is that these flaws are in a CPU, which is a component that's very difficult to change, so the existence of security flaws (that will only become clearer over time) seems worse than if it were in software. Maybe it's worse because of economic reasons (all the computers we have today will become obsolete because of security problems) or maybe because it's impossible to mitigate the flaws (the bugs are physically part of the hardware).

Also I remember that cryptographers consider any leaking of information about a secret to be a break. They call this "semantic security". Maybe there's something special about crypto that means people have to be maximally paranoid. I wonder what level of paranoia is appropriate for CPUs.

Actually, if NetSpectre can already leak information about a plaintext or secret key, then that already breaks all of cryptography from some cryptographers' point of view.

Another thing: Nation states may learn how to execute Spectre attacks faster than academia does. Then again, those same nation states would also want to switch to non-Spectre-prone computers, which would be visible enough for other people to start changing. Or maybe I'm putting too much faith in the IT skills of nation states.

Given all that, I don't know what safety margin is appropriate for CPUs. When do we consider all of our CPUs to be broken? Is it when Spectre attacks are being used to extract our financial info en masse? Is it soon? Or is it when governments start changing their computers (assuming governments are even that clever -- see the NHS and Wannacry)?

Depends on the level of automation possible in deploying a wide-scale attack, too.

Run some scripts, check on it six months later...oh look, we have SSL private keys for the X domains now.

In principle, yes. It's not a different exploit, it's just a different measurement technique for the timing (and one that most people wouldn't have expected to be possible).