My first highly amateur idea was to modify the frequency scaling algorithm with some randomness. How stupid is my idea?
[deleted]
Hertzbleed Attack
71–80 of 406 posts
Re: Hertzbleed Attack
#72jokes on them I disable turbo boost on all my machines because modern portables can't handle turbo boost anyway.
Re: Hertzbleed Attack
#73Earlier quoted context omitted.
I think this means you were paying for the over-provisioning i.e. paying for a full CPU or baremetal server? "The Cloud" is all about vCPU - "2 vCPUs" feels somewhat standard for a base-tier VPS... and 2 vCPUs means "2 virtual CPUs" or rather "roughly equivalent to 2 CPU cores" I think. I understand that jargon to mean they are always cramming 11 x 2vCPU clients onto 20 physical cores.
Nah, vCPU is generally just hyperthreading. See https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/cpu-opti... So you get 2 vCPUs per core.
Thanks for the link, that's great to know about AWS.
I don't think all other VPS providers are that good about things - googling around for some other definitions of vCPU (in VPS context) I see a lot of examples of 16 thread server CPUs handling "128 vCPUs".
Re: Hertzbleed Attack
#74If the frequency scale is known to user applications, I presume jittering response times proportional of the scale factor just before write() would be effective.
Re: Hertzbleed Attack
#75Something about this doesn't bother me as much as other side channels. To me, this reads like trying to predict the presence, make, model & operational schedule of someone's washing machine just by observing how fast their power meter spins over time. Unless you have an intimate awareness of all of the other power consuming appliances, as well as habits of the homeowner, you would have a hell of a time reaching any m…
You can say the same thing about all of these attacks. That they are tedious ways of collecting data. The problem is that computers can be made to repeat operations, over and over again. Leaking keys fractional bit by bit or what it is. That's why the attack doesn't work against someone's laundry machine - unless it's connected to the internet, that is.
Re: Hertzbleed Attack
#76A lot of people here commenting about shared hosting in clouds, but I don't see any actual text that shared environments are more vulnerable.
It sounds like a black box timing attack that could target my laptop, my phone, my server, anything that does cpu frequency scaling and is performing a computation that is susceptible to this attack.
Is that accurate?
Re: Hertzbleed Attack
#77I did my MEng, in part, on analyzing data dependent power usage in adders and I'm sort of embarrassed I didn't think of this.
Re: Hertzbleed Attack
#78Isn't it possible to monitor for this type of attack, and then apply mitigations?
Re: Hertzbleed Attack
#79Is the libsecp256k1 library affected? How hard is to fix it?
Re: Hertzbleed Attack
#80Earlier quoted context omitted.
There's so much variation (read, noise) intrinsic to response times for network requests to be satisfied on most cloud hosts anyway that I'm very skeptical about any practical attacks being made in the short term.
For one request, yes. For statistical analysis of many requests, no. People keep extracting secrets from very noisy and weak signals.
This is not inconsistent with what I said.