381–390 of 406 posts
This seems vaguely like when they would use page fault boundaries to extract passwords. An OS/hardware event that occurs within some if-then to leak parts of the "key".
Do we need some sort of "random delays" or binary execution randomization?
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…
Heck, isn't spying on keyboards and display signals through a wall still "practical"?
Why do we never get proactive defense against this sort of thing? As with speculative execution, caching, out-of-order execution, dispatching instructions to multiple ALUs depending on availability, etc, it was clear from the get-go that in principle the timing can depend on the payload so in principle it can be a problem for crypto. The need for constant time should have first class support on the language/compiler…
This is engineering, there's a lot of things that could happen but don't, we don't all run ECC RAM either. The problem is that speculative execution is really good and if Intel didn't have it they would've been selling worse CPUs. And to be clear, it was about 20 years from the point where people were seriously publishing theories about speculative execution attacks to the point where it was a practical attack. Think…
Earlier quoted context omitted.
> the attacker does in fact need to be able to get the targeted system to run something somehow Unfortunately that includes Javascript, and now that affects virtually everybody. Speculation: if you can find a Javascript call that uses protected keys, you might be able to extract secrets from that route.
OK, but can you walk me through the threat model here? This isn't a rhetorical question, it's easy to see how servers in general and shared hosting, colocated VMs etc in particularly might theoretically face a threat here, I'm just trying to get a better understanding of how GP would be correct for end user devices. The individual in question on the smartphone or computer specifically chooses to initiate a connection…
short secrets which aren't mitigated by MFA: session cookies, TLS client certificates, secret keys of e2ee IM apps (eg. Element), Zerobin URLs, ... Maybe even TLS session keys?
Earlier quoted context omitted.
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…
Interestingly, AWS takes no such actions against massive scans of infrastructure. One can acquire millions of cloud servers in search of co-residency without action being taken.
My point was more like - the moment it becomes known that people are doing that sort of thing, they would implement mitigations. Sucks if you're literally the first victim who detects what happened, but that's not many people, especially because this sort of "flood the server with data and measure timing" attacks are so noisy and visible.
Earlier quoted context omitted.
I think SIKE was just chosen because of its relevance, not because it has any particular issues that make it more susceptible. I'd be curious to hear from an expert on this.
SIKE is definitely not the most widely used cryptographic algorithm. And as the paper points out: > In our attack, we show that, when provided with a specially-crafted input, SIKE’s decapsulation algorithm produces anomalous 0 values that depend on single bits of the key. It was clearly selected for this property. The attack allows to determines the number of 0s and 1s in words processed by an algorithm, so they chos…
I would think that any kind of key exchange algorithm that relies on a constant time algorithm is vulnerable to this. I could be wrong.
Earlier quoted context omitted.
Interestingly, AWS takes no such actions against massive scans of infrastructure. One can acquire millions of cloud servers in search of co-residency without action being taken.
Sure, probably there are no people mounting such attacks today. My point was more like - the moment it becomes known that people are doing that sort of thing, they would implement mitigations. Sucks if you're literally the first victim who detects what happened, but that's not many people, especially because this sort of "flood the server with data and measure timing" attacks are so noisy and visible.
Earlier quoted context omitted.
> the attacker does in fact need to be able to get the targeted system to run something somehow >Unfortunately that includes Javascript, and now that affects virtually everybody. Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.
I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to. Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web? 99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up maliciou…
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…
Earlier quoted context omitted.
Presumably you can schedule only on non-information-leaking-boundaries with very high level APIs?
>non-information-leaking-boundaries Every one of the recent leaking boundaries were assumed to be non-leaking. You cannot just inject "non-leaking" into a statement and assume that solves anything.