Live data from Hacker News

Hertzbleed Attack

hertzbleed.com

351–360 of 406 posts

Re: Hertzbleed Attack

#351

Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large. Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/... The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack…

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…

[deleted]

Re: Hertzbleed Attack

#352

Earlier quoted context omitted.

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

I am curious as to your perspective as a physicist, do you think it is feasible to have a QC computer from an energy perspective? There is the cost to consider, yes, there is also an energy cost to a stable QC system. Asymmetric/symmetric are not unbeatable, they have an energy cost. Shors algorithm is theoretically great, but rarely if ever have I seen an associated energy cost...even outside of the answer "will we…

So, as nickelpro states, I feel like a QC that is actually general purpose (which is probably a better way to state it) is so difficult at this point to even imagine, it's hard to say it will become a thing absent some breakthrough that is hereto unknown. You probably could state it as an energy cost thing by somehow deriving how much energy it would take to keep millions of quibits from decohering by extrapolating from how much energy it takes to keep a few from decohering, but I'm not even sure you can extrapolate that far out since as you increase the number of quibits the required energy probably isn't linearly related to the number of quibits but it is some power law or worse. Remember, the number of quibits we can run is in the dozens today, the numbers you need for Shor's algo or just general purpose computing is likely in the millions.

For quantum people, the QCs are already pretty cool because they can do simulations of quantum systems like molecules and atoms that are just infeasible on classical computing (high performance computing, ie. supercomputer) systems, things that would take probably years (yes years) of wall time on a HPC system. The thing is the number of required quibits for modeling these types of molecules is likely in the dozens to 100+ quibits, which looks possible now since there are systems out there that, while noisy, do have dozens of operating quibits.

If you're curious what these simulations are for, it's doing things like calculating energy levels for certain molecules, which materials science people care about and will help them make the next generation subtrate for a computer chips, etc etc. So it's not entirely esoteric stuff, it will be things which will eventually make it into actual products and technology people use, but it definitely is NOT general purpose computing, even less so Shor's algorithm or breaking encryption.

Re: Hertzbleed Attack

#353
post #126

Earlier quoted context omitted.

What can an attacker do by knowing how many much queued crypto work there is?

There's lots of attacks currently on existing systems exploiting this. Leaking any information about other processes or supposedly hidden state of the system means you are leaking - and attacks always get better, not worse. The point is once you have shared, scheduled resources, others are going to get knowledge that they should not have. The rough idea is, say some other process is repeatedly running some known code…

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 cases you'd be right (I'm thinking of variable length audio encoding, where you could recover part of the conversations or voice prints from network analysis alone), and in these cases you mist hide sizes as well (basically use constant length audio encodings).

But in the general case, message sizes are much less important that you make it sound.

Re: Hertzbleed Attack

#354

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

Google researched the topic over 2.5 years last decade and did find a notable amount [1]. "Bitsquatting" has also been seen in the wild in the past decade [2]. [1] https://static.googleusercontent.com/media/research.google.c... [2] https://en.wikipedia.org/wiki/Bitsquatting

I stand corrected then. Thanks for the links.

Re: Hertzbleed Attack

#355

Earlier quoted context omitted.

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.

Yeah, it's good enough for decrypting message headers then handing the rest of the decryption to the much more powerful main CPU. But having it handle the whole encryption? You're going to wait a while.

Re: Hertzbleed Attack

#356

Earlier quoted context omitted.

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

My favourite term for such disambiguation is Cryptographically Relevant Quantum Computers.

Re: Hertzbleed Attack

#357

Hmm, it feels like Intel/AMD are ducking and just hoping that the implications of this are not large. Here's a video from Intel chatting with the researchers: https://community.intel.com/t5/Blogs/Products-and-Solutions/... The questions are incredibly weak from the interviewers. They first state that it's not practical because the attack could take many hours, even days. But they don't describe why a day-long attack…

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…

[deleted]

Re: Hertzbleed Attack

#358
post #238
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…

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…

If I remember correctly they also had to disable shared array buffers because a thread just incrementing a shared value can be used as timer.

Re: Hertzbleed Attack

#359
post #180

Earlier quoted context omitted.

On MacOS Low-Power mode in the Power section of system settings disables turbo-boost. On Linux echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo does the rick. Note that this is not the same as power-saving mode in Gnome settings. I have found that for heavy C++ compilation that lasts for many minutes the slowdown was about 20% on my ThinkPad X1 laptop. The big plus is that it made the laptop almost silent.

Any way to do it on Windows without getting into BIOS?

You can use tools like ThrottleStop [0]

I use it on my laptop and run it to disable turbo boost most of the time -interestingly for performance reasons. Turbo boost leads to very erratic behaviour on laptops when you have long running CPU-intensive tasks (e.g. the cores run hot and it has to throttle down hard to cool them down again).

[0] https://www.techpowerup.com/download/techpowerup-throttlesto...

Re: Hertzbleed Attack

#360
Can't intel and amd just change how long a core stays at a turbo frequency to mitigate this? I.e.: if it scales up by 1hz, it can't scale down by that much until N number of cycles.
Post reply on HN