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

391–400 of 406 posts

Re: Hertzbleed Attack

#391

Post by loup-vaillant »

ChrisLomont wrote: post #363
loup-vaillant wrote: post #353

Earlier quoted context omitted.

You're making a general hand wavy argument here, but this is a rather specific issue. "Constant time" in cryptography means that there is no information flow from secrets to timings. Keys are secret. Plaintexts are secret. Ciphertexts, and most importantly their size, is public . You're basically saying that leaking public information is dangerous. This is the same as saying it should be private. In some specific cas…

> Constant time" in cryptography means that there is no information flow from secrets to timings If "constant time" cryptography were achievable don't you think we'd have it and there'd be no more timing attacks breaking encryption schemes? "Constant time" cryptography is a mathematical abstraction, a goal, like "unbreakable cipher" and "unbreakable hash" and "frictionless surface." They don't occur in practice. This…

If you're going that route, everything is influenced by anything, and with a sufficiently advanced sensor array you could detect a butterfly flapping its wing across the globe.

If instead we get serious for a minute, we can notice that cryptography is not magic, and neither is the way data flows from secrets to timings. Quite obviously, whether a program's timings depends on its inputs or not is a function of the hardware it runs on more than anything else.

As long as energy consumption does not meaningfully influenced timings, we're actually in very good shape. Most CPUs have constant time arithmetic (multiplication may be more problematic), and the only way data flows from secrets to timings are branches and the cache. All we have to do is avoid secret dependent branches and secret dependent indices.

When energy does influence timings (frequency scaling, listening at an audio feed…), we're basically screwed, because no CPU instruction is constant energy. No way we can fix this without help from the hardware.

> coding up a constant time crypto and especially making it portable over time and architectures, is nearly impossible.

Sure. I'll settle for constant time now with my hardware. And I'll ask hardware vendors to pretty please sell me hardware that makes it possible.

---

In the mean time, I'll see what this new finding actually leads. I don't anticipate major disruption to be honest. The attack demonstrated here required 36 hours, in the lab. This is a far cry from AES cache timing attacks which took 65 milliseconds. I'll wait and see what actually breaks in realistic threat models.

Re: Hertzbleed Attack

#392

Post by mike_hearn »

theicfire wrote: post #389
mike_hearn wrote: post #344

Earlier quoted context omitted.

What you're seeing here is a collision between academic cryptography culture and real world engineering culture. In particular, the word "practical" has very different meanings in those two worlds, hence the discrepancy. In engineering, the word "practical" has an expansive definition that takes into account end goals, likely costs, rewards and risks of getting there, whether better approaches exist and so on. In aca…

Wow, amazing response. This was exactly what I was looking for. It's odd I have to get someone from HN to help me understand instead of, say, Intel/AMD. Their recommendations didn't seem to mention any of these important details. Maybe I missed something. Thank you!

You're welcome!

My experience has been that large companies won't directly argue with academic research, even when they easily could. Most people will automatically side with academics in any dispute, because they'll intuit that of course the company would say there's no real problem, they're conflicted, whereas the researchers aren't so the latter must be correct. Many people aren't too savvy about the publish-or-perish problem and don't care about the details. Corporate PR people also hate picking public fights, so tell staff to just roll with it and engage in damage control. After all, you're arguing with people who can literally spend all day writing up clever sounding papers about why their claimed problem is real, whereas you have customers to satisfy.

Re: Hertzbleed Attack

#393

Post by Terretta »

gralx wrote: post #375
Terretta wrote: post #250

Earlier quoted context omitted.

> So Intel *did* ask for a long embargo… > … again telling us that there indeed WAS a long embargo placed on this research by Intel. These are worded as if this wasn’t clear? No guesswork, the article states it plainly: ”We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Intel originally requested our findings be held under embargo unti…

You missed this part: > Only mentioning this here just in case the PR spin doctors threaten the researchers into removing mention of Intel on this one.

I didn't.... Continue the quote:

> Only mentioning this here just in case the PR spin doctors threaten the researchers into removing mention of Intel on this one. Which honestly I hope doesn't happen because my interpretation is that Intel asked for that long embargo...

Key part of that closing paragraph:

> ... my interpretation is that Intel asked for that long embargo ... and ... not everybody's going to come to that same conclusion...

If mentioning here to mitigate spin doctoring, the important thing to record in case Intel made them remove it would be the explicitly not open to interpretation paragraph I cited above.

Re: Hertzbleed Attack

#394

Post by icedchai »

_0w8t wrote: post #204
bobkazamakis wrote: post #147

Earlier quoted context omitted.

> the attacker does in fact need to be able to get the targeted system to run something somehow >Unfortunately that includes Javascript, and now that affects virtually everybody. Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.

When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be…

There were proof of concepts. Were there ever any actual real world attacks?

Re: Hertzbleed Attack

#395

Post by 2OEH8eoCRo0 »

throwaway742 wrote: post #327
2OEH8eoCRo0 wrote: post #228

Earlier quoted context omitted.

You can configure your CPU to always boost if you're really paranoid. It shouldn't run much hotter since the load doesn't increase, just the frequency.

Then why isn't that the default setting?

I didn't say temps or power won't rise, just that it's not a huge hit.

Re: Hertzbleed Attack

#396

Post by avianes »

staticassertion wrote: post #386
avianes wrote: post #374

Earlier quoted context omitted.

SIKE is definitely not the most widely used cryptographic algorithm. And as the paper points out: > In our attack, we show that, when provided with a specially-crafted input, SIKE’s decapsulation algorithm produces anomalous 0 values that depend on single bits of the key. It was clearly selected for this property. The attack allows to determines the number of 0s and 1s in words processed by an algorithm, so they chos…

I didn't think it was widely used, I'm sure it's very very rarely used. I was saying it was relevant because it represents the "future" of cryptography. I would think that any kind of key exchange algorithm that relies on a constant time algorithm is vulnerable to this. I could be wrong.

Not a cryptography specialist, but I doubt that all crypto algorithms have the same property of causing 0s (or 1s) to massively appear for some inputs in a way that could lead to a key leakage with this attack.

I believe that SIKE is an extrem case which allows to perform this attack with more ease.

However I suspect that by refining the attack then it could be extended to other algorithms less sensitive to power side-channel.

Re: Hertzbleed Attack

#397

Post by userbinator »

ziddoap wrote: post #287
userbinator wrote: post #258

I don't care! There, I said it. I didn't care about Spectre, Meltdown, or any of the other obscure timing side-channels that came after them either, because they relied on so much detailed information about the environment being attacked that you'd almost certainly be able to get the information you wanted by some much easier way. Attacking something that doesn't seem to be in much use either doesn't make me any more…

> we don't go feeding the paranoia machine and driving us even more towards the growing dystopia. It's an academic research paper with a website and a logo, it's not like they're broadcasting on the 6pm news. Would you rather the research not be done at all? Or just not posted on the websites you visit?

with a website and a logo

it's not like they're broadcasting on the 6pm news

They clearly wanted to get publicity, and didn't mention much how contrived the scenario they "attacked" really was.

Heartbleed was deserving of its logo and dedicated website; this one is nowhere near in severity but tries to act like it is.

Re: Hertzbleed Attack

#398

Post by _tk_ »

Djb says:

„This particular attack demo succeeded with toy models and toy signal processing, so I'd expect state-of-the-art models and state-of-the-art signal processing to extract secrets from many more programs, _except_ when users protect themselves by setting constant CPU frequencies.“

https://twitter.com/hashbreaker/status/1537188851440943105

Re: Hertzbleed Attack

#399

Post by jnordwick »

icedchai wrote: post #394
_0w8t wrote: post #204

Earlier quoted context omitted.

When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be…

There were proof of concepts. Were there ever any actual real world attacks?

never. nothing ever recovered in a root kit. nothing seen for sale. even the original POCs were horrible biased and didn't work. simple moving the targeted buffer around in memory would have make it virtually impossible to exfiltrate it.

Re: Hertzbleed Attack

#400

Post by tails4e »

Too wrote: post #318
tails4e wrote: post #187

Is it not possible to add noise by running other processes in parallel that will also cause frequency boosts to occur and colour the results? Bauscilaly the mitigation is to disable boost, but instead boosting more often or boosting in a controlled way (with another process triggering it) should so help mitigate.... That said if it was that trivial, surely intel or someone would suggest it.

Noise helps to increase the difficulty, but with a large enough sample size you can statistically exclude it, greatly simplified but essentially by doing X-avg(all X). Imagine you do the above bit for bit. So first you sample 1M times to find the baseline, then flip one bit and sample another 1M times to see if any deviations, and so on. There is also the chance of your PRNG being predictable, so attacker can predict…

True, but is it reasonable to assume the same key would be used for long enough on a go en operation to allow averaging to help? The mitigation only needs to work practically, not in a worst case theoretical situation.
Post reply on HN