This is a most excellent place for technology news and articles.
This requires local access to do and presently an hour or two of uninterrupted processing time on the same cpu as the encryption algorithm.
So if you're like me, using an M-chip based device, you don't currently have to worry about this, and may never have to.
On the other hand, the thing you have to worry about has not been patched out of nearly any algorithm:
Yeah I don't think this is a big-ish problem currently. But by having this vulnerability to point to, other CPU vendors have a good reason not to include this feature in their own chips.
Wow, what a dishearteningly predictable attack.
I have studied computer architecture and hardware security at the graduate level—though I am far from an expert. That said, any student in the classroom could have laid out the theoretical weaknesses in a "data memory-dependent prefetcher".
My gut says (based on my own experience having a conversation like this) the engineers knew there was a "information leak" but management did not take it seriously. It's hard to convince someone without a cryptographic background why you need to {redesign/add a workaround/use a lower performance design} because of "leaks". If you can't demonstrate an attack they will assume the issue isn't exploitable.
If you can't demonstrate an attack they will assume the issue isn't exploitable.
Absolutely. Theory doesn't always equal reality. The security guys submitting CVE's to pad their resumes should absolutely be required to submit a working exploit. If they can't then they're just making needless noise
There are definitely bullshit cves out there but I don't think that's a good general rule. Especially in this context where it's literally unpatchable at the root of the problem.
So the attack is (very basically, if I understand correctly)
Setup:
Attack:
Is this somewhat correct? Those speculative execution vulnerabilities always make my brain hurt a little
