There is proof-of-concept code for reproducing. I don't think sample count is a big concern.

That said, I believe the real caveat lies in the "workload must run for long enough to trigger frequency scaling" part. Usual crypto primitives are just too fast on our processors, which is likely why they picked SIKE to demo the attack.

Quantum computing as a practical platform has yet to be proven feasible. When you ask people who know what they're talking about and aren't pitching for grant money, quantum computing is somewhere between decades away [1] and never happening [2].

[1]: https://www.nature.com/articles/d41586-019-02936-3

[2]: https://spectrum.ieee.org/the-case-against-quantum-computing

We have, with superconducting circuits operating at 20 milli-kelvin, managed to corral 53 qubits into a circuit. In the error-correcting model, we must perform simultaneous gate operations on at least thousands of qubits. We have managed to perform simultaneous gate operations on two.

The levels of engineering effort required, and the orders of magnitude separating what has been realized by those efforts and what is required by theory, lends itself towards narratives of impossibility. Unlike the transistor revolution, there is no clear path forward upon which we might improve these initial results.

To quote my second source:

> I believe that, appearances to the contrary, the quantum-computing fervor is nearing its end. That’s because a few decades is the maximum lifetime of any big bubble in technology or science. After a certain period, too many unfulfilled promises have been made, and anyone who has been following the topic starts to get annoyed by further announcements of impending breakthroughs. What’s more, by that time all the tenured faculty positions in the field are already occupied. The proponents have grown older and less zealous, while the younger generation seeks something completely new and more likely to succeed.

> All these problems, as well as a few others I’ve not mentioned here, raise serious doubts about the future of quantum computing. There is a tremendous gap between the rudimentary but very hard experiments that have been carried out with a few qubits and the extremely developed quantum-computing theory, which relies on manipulating thousands to millions of qubits to calculate anything useful. That gap is not likely to be closed anytime soon.

> To my mind, quantum-computing researchers should still heed an admonition that IBM physicist Rolf Landauer made decades ago when the field heated up for the first time. He urged proponents of quantum computing to include in their publications a disclaimer along these lines: “This scheme, like all other schemes for quantum computation, relies on speculative technology, does not in its current form take into account all possible sources of noise, unreliability and manufacturing error, and probably will not work.”

Sorry for that, I have to context switch when I talk to people outside physics. I always forget that. Also definitely the context of the convo was about QCs breaking encryption so my bad.

There is the cost to consider, yes, there is also an energy cost to a stable QC system. Asymmetric/symmetric are not unbeatable, they have an energy cost. Shors algorithm is theoretically great, but rarely if ever have I seen an associated energy cost...even outside of the answer "will we build one" the question is "can you efficiently build one" or not, i.e. what does a QC capable of executing shor's algorithm look like, a small planet or star perhaps?

For quantum people, the QCs are already pretty cool because they can do simulations of quantum systems like molecules and atoms that are just infeasible on classical computing (high performance computing, ie. supercomputer) systems, things that would take probably years (yes years) of wall time on a HPC system. The thing is the number of required quibits for modeling these types of molecules is likely in the dozens to 100+ quibits, which looks possible now since there are systems out there that, while noisy, do have dozens of operating quibits.

If you're curious what these simulations are for, it's doing things like calculating energy levels for certain molecules, which materials science people care about and will help them make the next generation subtrate for a computer chips, etc etc. So it's not entirely esoteric stuff, it will be things which will eventually make it into actual products and technology people use, but it definitely is NOT general purpose computing, even less so Shor's algorithm or breaking encryption.

Personally I haven't seen much of this done in the real world.

Do you expect those who do carry out a successful attack to email you and let you know of their success? Or perhaps you think they'll exploit someone, and follow it up with an academic write-up of how they carried out that exploitation, to be widely published?

While security theatre does exist, it's laughable to write off an entire class of vulnerabilities as theatre.

If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot. It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed.

A school teacher wearing a condom is strictly speaking safer than the alternative, and yet someone should still be fired.

I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you think it's all theatre is naive. Weighing each exploit against your attack surface, risks, and risk tolerance is not.

>It's security theater specifically because individuals and organizations following these blind mitigation recommendations don't assess the attack surface that's being exposed.

Blaming researchers for security theatre when it is the organizations which are not doing their due diligence is, at least to me, a weird way to look at things.

I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just because their unsafe in specific application spaces, which seems to be what half of HN starts advocating for whenever this stuff comes up.

An application bug like OpenSSH is a completely separate spiritually from the hardware bugs that inspire these mitigation discussions.

The person I replied to asserted that all timing attacks are theatre, which I disagree with (and, evidently, poorly communicated my stance). Perhaps they did not mean the entire class of vulnerabilities which rely on some sort of exploitable timing difference, but only those that require privileged (or physical) access. In that case, I still believe it is foolish to completely dismiss them simply for being a 'timing attack' (and therefor theatre), but I also believe it is foolish to blindly follow mitigation recommendations without analysis.

And then you put 'mitigations=off' in your kernel command line and go on your way. I do it for all my BOINC compute nodes, because they literally have nothing sensitive on them.

But remember, L1TF/Foreshadow could reach across virtual machine boundaries. It's not just inter-process speculation that's a problem.

There's a reason this CVE is classified as medium severity

Probably 90% of PCs are single-user Windows desktops, though. It's a "nonexistent severity" issue for those use cases... yet we all get to pay.

On the other hand, if you're a cloud provider that multiplexes tons of virtual cores on your physical hardware, I suspect anyone trying to do the sort of careful timing analysis required for these types of attacks would find themselves drowning in noise, as their processes get migrated arbitrarily between cores of hardware shared with tons of others.

It's odd, because this agrees with what I wrote, and the parent to your comment says they "fully concur", yet they are arguing that I'm incorrect. I did a poor job in communicating.

As an attempt to better clarify what I wrote: I agree with you that for the vast majority of people this specific attack is a non-issue. But, there are plenty of different timing attacks, and some of those may affect some people. It would follow then that some timing attacks should not be abruptly dismissed simply because it's classified as a timing attack.

However, my initial comment was replying to someone who wrote off the entire class of vulnerabilities, asserting that no timing attack of any variety has been used successfully. I find this a naive approach to vulnerability management. Instead of dismissing all attacks that are classified as timing attacks, vulnerabilities should be assessed for what they can do, the ease of doing it, and the potential impact of a successful attack.

But they just straight up don't run in constant time, so they're vulnerable to a timing attack across the network. That's clearly just a library bug? Like surely the dumbest part of a "constant time" algorithm is double checking that you ran for a constant wall clock amount of time?

It's... hard. A lot of the "constant cache behavior" and "constant time behavior" algorithms were written back in the day when the CPU speeds didn't change randomly on you, or at worst toggled between "idle" and "running hard." Think... oh, even the Core 2 days, really. They didn't switch that fast.

And then the hardware behavior changed out from under the algorithms, and nobody noticed. Now the throttling is far more rapid. So they may still be "constant instruction count," but that no longer implies constant time.

It's... complicated. :( And what's worse, even the people in charge of managing the complexity don't understand all the details anymore. When stuff like this surprises Intel, we've got problems.

While this won't fool timing attacks that are operating on the same machine as your process, the computation time becomes completely opaque to the network which is what the "remote" attacks are built on.