4 ms·

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 abou

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.

wmf 4y ago
For one request, yes. For statistical analysis of many requests, no. People keep extracting secrets from very noisy and weak signals.
- jessermeyer 4y ago
  This is not inconsistent with what I said.
  - thfuran 4y ago
    Isn't it? It probably wouldn't require any novel statistical techniques.
    - jessermeyer 4y ago
      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'.
- mike_hearn 4y ago
  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.
  - api 4y ago
    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.
    - mike_hearn 4y ago
      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).
FabHK 4y ago
> 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”.
- jessermeyer 4y ago
  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".

wmf 4y ago

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

jessermeyer 4y ago
This is not inconsistent with what I said.
- thfuran 4y ago
  Isn't it? It probably wouldn't require any novel statistical techniques.
  - jessermeyer 4y ago
    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'.
mike_hearn 4y ago
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.
- api 4y ago
  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.
  - mike_hearn 4y ago
    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).

FabHK 4y ago

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

jessermeyer 4y ago
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".