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

301–310 of 406 posts

Re: Hertzbleed Attack

#301

Post by thristian »

contravariant wrote: post #245
jabart wrote: post #238

Earlier quoted context omitted.

My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the…

Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?

Same as any security: making an attack more expensive to mount means people are less likely to try it. If high-resolution timers allow you to mount an attack in the three minutes the target takes to read a listicle page, then rounded timers require the target to keep the page open in the foreground for 3000 minutes, or 50 hours. That's much more difficult to do.

Re: Hertzbleed Attack

#302

Post by WXLCKNO »

justinclift wrote: post #292

From the AMD advisory, it seems like desktop Ryzen 5000 series aren't affected, nor 3rd gen and later EPYC. Pretty much everything else is: https://www.amd.com/en/corporate/product-security/bulletin/a...

Not sure why though, my 5900x has precision boost. Wonder what's different.

Re: Hertzbleed Attack

#303

Post by jaza »

pyrolistical wrote: post #129
kevingadd wrote: post #56

Earlier quoted context omitted.

The frequency change is observable by the whole algorithm taking a different time to run - the algorithm is constant-time, but because the clock speed is changing based on the data, it's not constant-wall-clock-time and you can perform a timing attack.

Haha so constant time algorithm isn’t constant time

Time itself isn't constant, so arguably a constant time algorithm is an oxymoron! But that's a whole 'nother topic.

Re: Hertzbleed Attack

#304

Post by noobermin »

nickelpro wrote: post #297
noobermin wrote: post #291

Earlier quoted context omitted.

"Never happening" is way too harsh imo, but it definitely is still decades away.

You need on the order of millions of qubits for quantum error correction algorithms to work. We have, with superconducting circuits operating at 20 milli-kelvin, managed to corral 53 qubits into a circuit. In the error-correcting model, we must perform simultaneous gate operations on at least thousands of qubits. We have managed to perform simultaneous gate operations on two . The levels of engineering effort require…

Ok, as a scientist, when I say "never" is too harsh, what I mean by QCs becoming a thing probably isn't what most people on HN think of as QCs but rather being objects for simulating quantum systems. For that, they already have use (that is, those QC systems you keep hearing about on the news that already exist and are being used) and probably will get better to the point (god willing) we can simulate many electron systems. That is _my_ dream. I feel like QCs in HN minds is a lot more towards the "Computer" part of QC, like an actual Turing complete computer that will be able to do Shor's algorithm and break modern encryption, and on that I sort of agree with your assessment that it is between decades to never.

Sorry for that, I have to context switch when I talk to people outside physics. I always forget that. Also definitely the context of the convo was about QCs breaking encryption so my bad.

Re: Hertzbleed Attack

#305

Post by HappyTypist »

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 many consumer OS crashes can be attributed to RAM errors?

How many corrupt files, strange bugs, or quirks can be attributed?

Re: Hertzbleed Attack

#306

Post by danielheath »

vajrabum wrote: post #290
contravariant wrote: post #245

Earlier quoted context omitted.

Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?

Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?

Example: You need to know how whether an operation takes 30 or 31 milliseconds, but your timer is rounded to the nearest 100ms, so you just get 0 or 100.

If you repeat the operation 100 times and time how long that takes, you should either get 3000 or 3100 milliseconds.

Re: Hertzbleed Attack

#307

Post by nayuki »

Is the long-term solution some kind of balanced binary encoding where two wires represent a bit, with exactly one wire high and one wire low?

Re: Hertzbleed Attack

#308

Post by fomine3 »

culpable_pickle wrote: post #178
hinkley wrote: post #49

I suspect what we are seeing in the last few years is the slow death of purely symmetric multiprocessing. At the end of this I wonder if we'll see processors with one or two cores dedicated to cryptographic primitives, where the ALU has a fixed IPC, the core has a very limited number of clock rates, and the caches are sized to prevent eviction when running common cryptographic algorithms.

Wouldn’t the TPM fit those requirements, presuming it could be sped up enough for the required workload

Currently TPM is connected via very narrow bus.

Re: Hertzbleed Attack

#309

Post by fomine3 »

agucova wrote: post #299
kccqzy wrote: post #280

> We disclosed our findings, together with proof-of-concept code, to Intel, Cloudflare and Microsoft in Q3 2021 and to AMD in Q1 2022. Why did they choose to disclose their findings to just two software companies (Cloudflare and Microsoft)? Why not other software companies like Amazon or Google? Or developers behind open source cryptography libraries?

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?

Re: Hertzbleed Attack

#310

Post by sam0x17 »

syrrim wrote: post #135
sam0x17 wrote: post #118

So I take it when they say "constant time" for things like SIKE, they aren't sleeping for X milliseconds, but are just using some operation that is thought to be effectively constant time, hence this vulnerability? What is the countermeasure for this? Are crypto systems that always wait a full second using system timers, for example, immune to this sort of thing, or is it still detectable even in those circumstances?

>Are crypto systems that always wait a full second using system timers, for example, immune to this sort of thing No. Such a crypto system would still leak information via the amount of power it consumes, which might change the frequency of the cpu, which could be measured by an attacker through the other processes of the computer.

ah ok I was assuming over public internet timing attacks. This requires local hardware access or a local ssh account. Got it
Post reply on HN