Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

Post reply on HN
Print view View original

401–406 of 406 posts

Re: Hertzbleed Attack

#401

Post by api »

mike_hearn wrote: post #137
wmf wrote: post #66

Earlier quoted context omitted.

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 c…

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.

Re: Hertzbleed Attack

#402

Post by mFixman »

Can anyone ELI-CS graduate this vulnerability?

My understanding from reading the page is that modern processors process certain data with higher frequency, and somehow that allows an attacker to know guess private keys.

However, I don't understand the connection between those two things. How would an attacker trigger a lot of almost-identical CPU runs without hitting some rate limit somewhere? And how is this different than just guessing the password?

Re: Hertzbleed Attack

#403

Post by midislack »

Yet another embargo assented to, which appears to be pointless. Maybe the spy agencies wanted time to develop an exploit? Who knows.

"Responsible" disclosure is cancerous.

Re: Hertzbleed Attack

#404

Post by mike_hearn »

api wrote: post #401
mike_hearn wrote: post #137

Earlier quoted context omitted.

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 c…

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

Re: Hertzbleed Attack

#405

Post by angry_octet »

mgiampapa wrote: post #195
xoa wrote: post #155

Earlier quoted context omitted.

OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…

On most shared infrastructure would be even harder to exploit. In an ideal world you are sharing the infrastructure to maximize CPU and other resource utilization. When running workloads on VMWare for example, the best practice is to disable deep C states and not allow the CPU to dynamically scale down. This prevents all kinds of clock drift issues in guest VMs that expect a CPU cycle to be relatively constant.

This is not about power saving, it is dynamically, on the granularity of individual instructions, balancing the thermal dissipation available across cores. When some cores are relatively idle (e.g. waiting on cache fill) it uses the available amps to run other cores at "turbo boost" frequencies.

For some single threaded code we force other cores to idle so that one thread can get maximum cache and maximum frequency. A similar approach could be used to minimise the power analysis signal.

Re: Hertzbleed Attack

#406

Post by agucova »

fomine3 wrote: post #309
agucova wrote: post #299

Earlier quoted context omitted.

The attack in question was only tested on SIKE, so it seems logical to start targeted disclosure on the community using and developing it, while using the general disclosures to target the broader cryptographic community. Both Cloudflare and Microsoft are one of the few companies that have put significant investments into developing SIKE for post-quantum cryptography. Microsoft has a SIKE research team, and Cloudflar…

But it seems that SIKE isn't widely deployed yet. Should it be preferred?

SIKE is promising, but lacks research and maturity. It is mostly not ready for real-world use.
Post reply on HN