On: New vuln in Apple M-series allowing secret keys ex...

[mort96]

Noise doesn't protect against that, statistics is a thing.

But I think you might overall be right that this requires two colocated processes: the paper talks about how the DMP breaks assumptions made by "the constant-time programming model", and I took this to mean that constant-time algorithms aren't constant-time any more. Reading more closely, I think maybe the issue is that "the constant-time programming model" was also assumed to make secrets safe from cache timing side-channels leaking the secrets to other processes on the same CPU, and this seems like it might be the assumption that's broken by the DMP...

I'll have to read more, I've just skimmed the abstract and introduction so far.

[usrusr → mort96]

My attempt at skimming for "what would be needed": controlled input specifically designed to make the process with the keys speculatively fetch or not fetch address lookalikes depending on key bits, and some observer comparing timing either of fetches to canary addresses after the key has or has not triggered a fetch, or observing how the timing of the crypto parts changes with our without canary fetches beforehand. Or perhaps even outside observability from inputs that would either fetch the same canary address twice, or two separate address, depending on key bits?

In any case, the stack of "this could not possibly be workable / but with enough statistics it can, and computers are plenty fast to generate statistically useful case numbers" is truly mindboggling with these attack vectors.