Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

291–300 of 406 posts

Re: Hertzbleed Attack

#291
post #142

Earlier quoted context omitted.

SIKE is a very relevant example because we are slowly creeping toward a world where Quantum computing will be ubiquitous and existing asymmetric cryptography will face serious challenges.

We are nowhere near "ubiquitous" quantum computing. We aren't near rare quantum computing. Quantum computing as a practical platform has yet to be proven feasible. When you ask people who know what they're talking about and aren't pitching for grant money, quantum computing is somewhere between decades away [1] and never happening [2]. [1]: https://www.nature.com/articles/d41586-019-02936-3 [2]: https://spectrum.ieee…

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

Re: Hertzbleed Attack

#293

Earlier quoted context omitted.

None of the attacks are feasible in a trusted environment. If your code isn't running in an environment where other processes from untrusted sources are also running, these timing side-channels and their mitigations are irrelevant. If an untrusted source gets shell access to your trusted platform/server/container and can run payloads, you're already screwed six ways from Sunday and the rest of the discussion is moot.…

Not all timing attacks require any sort of privileged access. As one example, OpenSSH had a timing attack where under certain configurations a query for a non-existent user returned faster than an existing user, allowing attackers to enumerate user accounts. I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you t…

nickelpro did not blame researchers, but I will point out researchers are under a number of incentives to push this out and hype up the potential threat level of their work because it boosts their works' credibility and thus citations and ultimately funding. Researchers are better than most bad actors but they are not and cannot be completely pure actors not harboring even a tinge of potentially bad incentives.

Re: Hertzbleed Attack

#294
post #249

Earlier quoted context omitted.

Turbo will move the processor above the rated TDP when there is thermal headroom to do so. Turning it off means you'll max out at the rated TDP. Now, TDP used to mean the max power of the chip, but as Intel's process failures left them holding the bag with no significant performance updates to speak of, they started overclocking their chips more and more so they could claim that the new gen was faster than the last.…

Wow. How to they get their score in benchmarks? You can't "temporarily overclock" your cpu for too long right?

You can keep it up if everything can handle the current and heat.

A typical Intel chip on default behavior will go to maximum boost, limited by watts, for about half a minute. Then it will drop to a lower number of watts. Note that base clock gets ignored here; in this mode the base clock is just a minimum promise.

Many desktop motherboards easily or even automatically remove the time limit.

Re: Hertzbleed Attack

#295

Earlier quoted context omitted.

Not all timing attacks require any sort of privileged access. As one example, OpenSSH had a timing attack where under certain configurations a query for a non-existent user returned faster than an existing user, allowing attackers to enumerate user accounts. I'm not saying this specific attack is something to get worked up over. But, as I have already said, writing off an entire class of vulnerabilities because you t…

I don't blame the researchers, this is specifically against the nonsense discussions that plague this thread and others like it talking about the performance impact on personal computers. These side-channel bugs are minor annoyances, and mostly a problem for cloud providers. I wouldn't want Intel or AMD or anyone else to abandon speculative execution, clock boosting, or any other of the "vulnerable" technologies just…

Another example, I work in scientific high performance computing. The worst that can happen with my work (although people in more defense oriented research might care) is someone might see my data before I publish it...woopy doo, and I guess if they do, they'll have to spend the few hours needed to process TBs of data I make so they can what, scoop me? Oh and they have to access to the same supercomputer too... the risk I face of anything bad happening to me is minuscule. On the other hand, removing modern processor features like speculative execution and frequency scaling would mean my increase in execution time would mean going from 3 weeks or so to 4 weeks or more per simulation? No, I am NOT okay with that at fucking all, it's hard enough dealing with the multiweek delay I have before I can iterate, making that even longer for very little risk is not worth it.

Re: Hertzbleed Attack

#296

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…

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.

Tell that to my intel macbook.

Seriously, using a popular Turbo Boost Switcher makes it a lot colder and live longer on a battery

Re: Hertzbleed Attack

#297

Earlier quoted context omitted.

We are nowhere near "ubiquitous" quantum computing. We aren't near rare quantum computing. Quantum computing as a practical platform has yet to be proven feasible. When you ask people who know what they're talking about and aren't pitching for grant money, quantum computing is somewhere between decades away [1] and never happening [2]. [1]: https://www.nature.com/articles/d41586-019-02936-3 [2]: https://spectrum.ieee…

"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 required, and the orders of magnitude separating what has been realized by those efforts and what is required by theory, lends itself towards narratives of impossibility. Unlike the transistor revolution, there is no clear path forward upon which we might improve these initial results.

To quote my second source:

> I believe that, appearances to the contrary, the quantum-computing fervor is nearing its end. That’s because a few decades is the maximum lifetime of any big bubble in technology or science. After a certain period, too many unfulfilled promises have been made, and anyone who has been following the topic starts to get annoyed by further announcements of impending breakthroughs. What’s more, by that time all the tenured faculty positions in the field are already occupied. The proponents have grown older and less zealous, while the younger generation seeks something completely new and more likely to succeed.

> All these problems, as well as a few others I’ve not mentioned here, raise serious doubts about the future of quantum computing. There is a tremendous gap between the rudimentary but very hard experiments that have been carried out with a few qubits and the extremely developed quantum-computing theory, which relies on manipulating thousands to millions of qubits to calculate anything useful. That gap is not likely to be closed anytime soon.

> To my mind, quantum-computing researchers should still heed an admonition that IBM physicist Rolf Landauer made decades ago when the field heated up for the first time. He urged proponents of quantum computing to include in their publications a disclaimer along these lines: “This scheme, like all other schemes for quantum computation, relies on speculative technology, does not in its current form take into account all possible sources of noise, unreliability and manufacturing error, and probably will not work.”

Re: Hertzbleed Attack

#298
post #240

Earlier quoted context omitted.

This has almost no similarities to stuxnet. A more analogous hypothetical attack to stuxnet would be if they repeatedly cycled spinning rust drive heads in a certain way to cause the motors to fail and corrupt data, all the while faking the SMART data of the drive to not report drive head parking cycles. Your understanding of either this attack and/or stuxnet is flawed.

Rspndplz. Defute

They did.

Also if this counts as "Cause some crazy busllshit at a very small level, targetting specific people, such that I get the outcome I want!" then so does every vulnerability.

Re: Hertzbleed Attack

#299
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 Cloudflare has been exploring SIKE for post-quantum TLS for years.

Both companies also maintain the key open-source implementations of SIKE [1][2], and Microsoft is spearheading the effort to standardize SIKE through NIST. Most open source cryptographic libraries don't implement SIKE.

[1]: https://github.com/cloudflare/circl [2]: https://github.com/Microsoft/PQCrypto-SIKE

Re: Hertzbleed Attack

#300

"Hertz" means "heart" in German, so the name is a pun on "heartbleed" and the unit for frequency

Almost, the word for "heart" is spelled "Herz".

I think it's still intended as a pun as Hertz (the physical unit and the name of Heinrich Hertz) and Herz are pronounced alike.

Wikipedia and Wiktionary also have some suggestion that the name Hertz is etymologically related to the word Herz, although they disagree about exactly how.

Post reply on HN