There's so much variation (read, noise) intrinsic to response times for network requests to be satisfied on most cloud hosts anyway that I'm very skeptical about any practical attacks being made in the short term.

For one request, yes. For statistical analysis of many requests, no. People keep extracting secrets from very noisy and weak signals.

In lab conditions, yes. In this case:

"Our attack is practical; an unoptimized version recovers the full key from a CIRCL server in 36 hours and from a PQCrypto-SIDH server in 89 hours ... The target server and the attacker are both connected to the same network, and we measure an average round-trip time of 688 µs between the two machines."

Note that:

• The server in this case does absolutely nothing except use the cryptographic library. Would it work on a real server that actually does something useful with the requests? We don't know, the paper doesn't try that.

• We aren't told if it works if other people are using the server simultaneously.

• They show the attack against obscure post-quantum algorithms nobody actually uses (as far as I know). Why not RSA or ECDSA or something more standard? Presumably they don't have a technique that works on those, as otherwise it'd have been a big upgrade to their paper.

• What about if you aren't running your attack physically right next to your target? Is <1msec of latency what people think of when they hear "remote attack"?

I'm not hugely surprised Intel has limited themselves to issuing guidance. This paper continues a trend that's emerged since the first Meltdown/Spectre breaks in 2018 in which attacks become ever more convoluted, theoretical and unlikely to work outside of a lab yet they're all presented as equally important by the academics who develop them. I used to follow this area of research quite closely but eventually got sick of it. Way too many papers had some bizarre caveat buried deep in the paper, e.g. eventually I noticed that a lot of attacks on Intel SGX that claimed to leak cryptographic keys turned out to be using an extremely specific version of GnuTLS. I got curious why that might be and discovered that it was absolutely ancient, dating from many years before the papers were written. They were using it because that version had no hardening against side channel attacks of any kind whatsoever. Was that a realistic assumption to make for these attack papers? Probably not, but to notice this sort of trick you had to read well beyond the headlines.

I also remember some years ago, Google researchers got worried people weren't taking Spectre seriously enough, so they released a demo that claimed it would show a Spectre attack in action inside the browser. I was keen to see this because so many posited attacks seemed to rely on extremely specific situatons that didn't seem particularly plausible in the real world. I visited it in Chrome on macOS, i.e. one of the most predictable hardware and software environments the developers could have, and it didn't work. Checked reddit, it was filling up with people saying it didn't work for them either.

In the ~5 years since these attacks came out and started being patched in software and hardware, have there been any real world attackers found using them? Maybe but I don't remember hearing about any. State sponsored attackers seem to be sticking with more conventional techniques, which probably says a lot.

The obvious target for these is the cloud, especially second-tier cloud vendors more likely to be using "stock" KVM/XEN and therefore easier to target. The obvious target within these clouds would be cryptocurrency nodes.

I feel like if this had been exploited in the wild you would have already heard stories of people using it to zark someone's bitcoin off a Digital Ocean or Vultr node.

I don't think there's a way to apply this to cryptocurrency nodes, because they won't sign messages given to them by third parties over and over with their private keys (usually at least).

This is not inconsistent with what I said.

Isn't it? It probably wouldn't require any novel statistical techniques.

Novel statistical techniques is a different concern to practical attacks. (And I appreciate the relativity in what is meant by 'practical' -- nation state resources are in a distinct category of capability)

But I would like to see some statistical expectations on 'how long you'd have to wait on an average open network for each key bit to reach 95% confidence'.

> Hertzbleed is a real, and practical, threat to the security of cryptographic software. We have demonstrated how a clever attacker can use a novel chosen-ciphertext attack against SIKE to perform full key extraction via remote timing, despite SIKE being implemented as “constant time”.

Please. If you actually read the paper you'll come to learn that "practical" here means "we've conclusively shown under strict laboratory conditions that this works".

> since those tend to run at a sustained max anyway

Really? I've never been on the cloud-provider side of cloud computing, but every application I've developed that ran on the cloud was rarely if ever running at a sustained maximum of the resources allocated to it. We always wanted a buffer to be able to absorb load spikes and users performing unusually expensive actions.

Dynamic scaling involves bringing the CPU frequency down but not off - you can get almost as much power savings for some loads by using the old HLT instruction, so your CPU/core is either at full speed or basically off.

I am on the cloud provider side; we would sometimes limit the upper and lower range of frequency but completely disabling scaling would be very unusual.

Same. Our compute hosts are generally not using 100% of their cores at all time.

There’s computes that are not full, computes that run rather diverse tenants, and even the fully utilized computes responsible for CPU optimized VMs have enough variance in their workload for frequency scaling to occur.

I think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server?

"The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.

Nah, vCPU is generally just hyperthreading. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-opti...

So you get 2 vCPUs per core.

Thanks for the link, that's great to know about AWS.

I don't think all other VPS providers are that good about things - googling around for some other definitions of vCPU (in VPS context) I see a lot of examples of 16 thread server CPUs handling "128 vCPUs".

No, 2 vCPUs is 2 logical threads, which is equivalent to a single physical core on x86. So yeah, they are cramming 11 x 2 vCPUs onto 20 physical cores. In fact, it's more like 20 x 2 vCPUs.

Depends on the cloud - OVH and Digital Ocean yes, but AWS give you whole uncontested cores ( bar the t* instance line, but that's it's whole thing).

That only means you were making space for others to phase in and use the remaining resources that you spared. You're not the one deciding which process sits on which resource, after all.

The only reason why resources might be left unused are usage spikes that all customers share.

Depends on your workload, spot batch jobs would run at sustained maximum.

Absolutely, my observation is in a way that "most workloads don't seem (to me) to be like that".

The number of servers serving interactive queries (frontends, rest api servers, databases, etc) seems (to me) to greatly outnumber the number of batch jobs, and I've always seen those intentionally "over" provisioning CPU because otherwise you get latency issues if load increases at all.

I don't actually know that cloud providers don't either have some clever way around this (e.g. spending spare CPU cycles on some other form of work), or that it isn't the typical usage pattern, but I strongly suspect it.