5 ms·
Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server ru
by planb 4y ago
Ok, I See how this works in theory. But until I see an exploit that uses this method in real life to extract keys (or maybe any memory content) from a server running real life workloads, I am extremely skeptical. How much samples are needed to get anything useful? And wouldn't the time required to acquire these samples be longer than the time required to detect the attack (or even all keys to be shifted)?
- klysm 4y ago> time required to detect the attack Personally I haven't seen much of this done in the real world.
- melenaboija 4y agoNot trying to be disrespectful and it is true curiosity, what is your role to have to deal with this type of attacks (as much as can be disclosed) and could you please quantify “much”?
- CamperBob2 4y agoI haven't seen ANY side-channel timing attacks performed in the real world, but that doesn't stop the Security Theater crowd from costing us hundreds of millions of dollars and megatons of unnecessary carbon emissions by slowing everyone's CPU performance on the grounds that everyone's threat model is the same.
- ziddoap 4y agoThere are several (dozens) of papers showing the practicality of various timing attacks written by highly respected academics. Just because you haven't stumbled across an attack in the wild one does not somehow invalidate that there are practical attacks. 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.
- nickelpro 4y agoNone of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. 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.
- Syonyk 4y ago> If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. 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.
- nickelpro 4y agoYep, and yet everyone in this thread seems to be rushing to kneecap their own performance, for what? My laptop isn't a GKE node. There's a reason this CVE is classified as medium severity
- CamperBob2 4y agoI think the one-dimensional severity classification is part of the problem. If you're running a cloud provider, it's a much bigger deal. Call it "high severity" issue for those use cases. No objection to that, better safe than sorry. 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.
- rfoo 4y ago> How much samples are needed to get anything useful? 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.
- samus 4y agoSIKE is a very relevant example because we are slowly creeping toward a world where Quantum computing will be ubiquitous and existing asymmetric cryptography will face serious challenges.
- nickelpro 4y agoWe are nowhere near "ubiquitous" quantum computing. We aren't near rare quantum computing. 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 https://www.nature.com/articles/d41586-019-02936-3 [2]: https://spectrum.ieee.org/the-case-against-quantum-computing https://spectrum.ieee.org/the-case-against-quantum-computing
- noobermin 4y ago"Never happening" is way too harsh imo, but it definitely is still decades away.
- nickelpro 4y agoYou need on the order of millions of qubits for quantum error correction algorithms to work. 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.”
- gmiller123456 4y agoMy bet is that you could write all of your passwords on your front door and still not be victimized in any meaningful way. But, in many/most cases, it's cheaper to thwart the attack than to analyze if it can be used to exploit your systems.