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

251–260 of 406 posts

Re: Hertzbleed Attack

#251

Post by matthewdgreen »

abiro wrote: post #201
matthewdgreen wrote: post #26

Earlier quoted context omitted.

This is not entirely true. Or rather: it is true when the countermeasure is to add random delays to pad out overall timing, since one can simply collect more samples to obtain an average. And that may be what the OP is suggesting: just scale the frequency to random levels that are not quite the pre-programmed ones, which is very similar to adding random delays. (In practice this might actually work well enough to def…

How about making operations constant time in application code by picking an upper bound which is acceptable for the application, but that is certainly longer than the actual CPU computation and then waiting until the upper bound to return the result? Eg. my app is performing digital signatures and I'm sure that they take <1ms CPU time, but performing digital signatures in 10ms is acceptable for my application, so whe…

What you are describing is called “quantization”. It has some disadvantages, one of which is that people tend to disable it the second they hit a use case that requires better performance. It is also sometimes possible to distinguish “doing nothing and waiting for a timer” from “actively computing the result” if you have other access (eg you can measure response time by making another connection.)

Re: Hertzbleed Attack

#252

Post by jakogut »

hsuduebc2 wrote: post #247
MrWiffles wrote: post #2

Brilliant approach, really. Never occurred to me to try something like this! Are you affected? Very likely. What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.) One thing I found interesting that may get changed later, so I'm documenting it here, is in their FAQ they…

I'm not getting the part how disabling turbo boost lowers your cpu performance. It should only significantly increase power consumption right?

Disabling turbo boost/frequency boosting would actually _decrease_ power consumption, as well as performance. The idea with boosting is to allow certain cores to exceed the maximum frequency, so long as certain parameters such as package temp, core temp, and power usage are within certain thresholds. This allows workloads that don't push the entire CPU to its limits to run faster, as the few cores that are in use can run at higher frequencies and increased performance per core, at the cost of higher power usage per core and lower efficiency.

Re: Hertzbleed Attack

#253

Post by nickelpro »

Syonyk wrote: post #233
nickelpro wrote: post #213

Earlier quoted context omitted.

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…

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

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.

Re: Hertzbleed Attack

#255

Post by int_19h »

gambiting wrote: post #227
goodpoint wrote: post #221

Earlier quoted context omitted.

> we don't all run ECC RAM either ...because Intel placed profit above user's needs and choose not to allow ECC on desktops. Similarly, many other things have been made insecure by plain greed.

The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).

How do we know that it didn't?

Re: Hertzbleed Attack

#256

Post by hunterb123 »

goodpoint wrote: post #231
gambiting wrote: post #227

Earlier quoted context omitted.

The other way of looking at it is that a huge portion of the market is running non-ECC ram and it hasn't resulted in any measurable reduction of security or stability of operating systems worldwide. So maybe it really isn't necessary for your average user, and manufacturing ECC ram for users who ultimately don't need it would be just a waste(both financial and environmental).

> hasn't resulted in any measurable reduction of security or stability of operating systems worldwide Except it did.

By how much?

Re: Hertzbleed Attack

#257

Post by walrus01 »

> What can you do about it? Nerf your CPU performance by disabling "turbo boost" or equivalent. Should you do it? Probably not unless you're particularly vulnerable (journalist, human rights activist, etc.)

Would not another option be to do something that temporarily maxes out the CPU and forces it into boost mode, immediately prior to executing the crypto operation? But not for such a long duration that the CPU reaches any thermal limits and decreases its speed again.

Obviously energy inefficient and not good for laptops or portable devices.

Re: Hertzbleed Attack

#258

Post by userbinator »

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 worried either. Go after e.g. TLS, SSH, AES, RSA, etc. if you want to get our attention, but I suspect that trying this in practice, you're going to be overwhelmed by all the other sources of noise --- especially over a network connection -- that you won't be very successful at all. They mention 36h and 89h to get the key (few dozen bytes), and I assume that was in a basically ideal environment with nothing else to measure.

Those of us familiar with hardware would know that things like this are pretty natural; but unlike these people, we don't go feeding the paranoia machine and driving us even more towards the growing dystopia.

Re: Hertzbleed Attack

#259

Post by B1FF_PSUVM »

saagarjha wrote: post #237
samstave wrote: post #230

Earlier quoted context omitted.

Quoted post unavailable.

Being unnecessarily cryptic and sounding like a crackpot while calling everyone else out for being uninformed is generally unlikely to get you support on Hacker News.

Also advised: "Be kind. Don't be snarky. Have curious conversation; don't cross-examine. Please don't fulminate. Please don't sneer, including at the rest of the community."
Post reply on HN