4 ms·

Yep, 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 c

Yep, 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 ago
I 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.
- nickelpro 4y ago
  Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time" 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?
  - Syonyk 4y ago
    > 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.
    - nickelpro 4y ago
      Sure, but you can just check the high precision wall-clock timer at the end of your computation and makes sure you took at least X nanoseconds, and pad that out so that X is always greater than the amount of wall-clock nanoseconds the actual computation takes. Then, following a computation, you sleep until X. 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.
- ziddoap 4y ago
  >. 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. 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.
- userbinator 4y ago
  If you're running a cloud provider, it's a much bigger deal. 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.

Yep, 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 ago

I 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.

nickelpro 4y ago
Fully concur, although now that I've read some of the white paper some of this doesn't even appear to be a real issue? Like the claimed "remote" attacks against, "Cloudflare’s Interoperable Reusable Cryptographic Library (CIRCL) [28], written in Go, and Microsoft’s PQCrypto-SIDH [65], written in C ... [are] meant to run in constant time" 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?
- Syonyk 4y ago
  > 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.
  - nickelpro 4y ago
    Sure, but you can just check the high precision wall-clock timer at the end of your computation and makes sure you took at least X nanoseconds, and pad that out so that X is always greater than the amount of wall-clock nanoseconds the actual computation takes. Then, following a computation, you sleep until X. 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.
ziddoap 4y ago
>. 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. 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.
userbinator 4y ago
If you're running a cloud provider, it's a much bigger deal. 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.