[tsimionescu]

But the problem is not OpenSSL, it's that malicious code on the system can read the keys OpenSSL is using. If you don't run malicious code on the same system as OpenSSL, this attack goes away - there's no way to run a CPU timing attack from a different network.

[jval43]

"Remote Timing Attacks Are Practical" (2003):

https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

That's on the local network. I remember a paper doing this over the internet, but couldn't find it. A similar one over the internet:

https://www.usenix.org/conference/usenixsecurity20/presentat...

But in practice it's going to be malicious JS running in your browser: https://www.schneier.com/blog/archives/2021/03/exploiting-sp...

[mort96]

From what I understand, the problem is that algorithms which should be constant time are actually taking a variable amount of time depending on the data. If I have some server software whose security depends on those constant-time algorithms actually being constant time, why shouldn't this be exploitable over the network?

[DougBTX]

The mechanism is described in the FAQ here: https://gofetch.fail

> The GoFetch attack is based on a CPU feature called data memory-dependent prefetcher (DMP), which is present in the latest Apple processors. We reverse-engineered DMPs on Apple m-series CPUs and found that the DMP activates (and attempts to dereference) data loaded from memory that "looks like" a pointer. This explicitly violates a requirement of the constant-time programming paradigm, which forbids mixing data and memory access patterns.

> To exploit the DMP, we craft chosen inputs to cryptographic operations, in a way where pointer-like values only appear if we have correctly guessed some bits of the secret key. We verify these guesses by monitoring whether the DMP performs a dereference through cache-timing analysis. Once we make a correct guess, we proceed to guess the next batch of key bits. Using this approach, we show end-to-end key extraction attacks on popular constant-time implementations of classical (OpenSSL Diffie-Hellman Key Exchange, Go RSA decryption) and post-quantum cryptography (CRYSTALS-Kyber and CRYSTALS-Dilithium).

It sounds like the OpenSSL code is still constant time (it doesn't expect pointers in the intermediate values, to OpenSSL it is just data, not something it will ever dereference) but the attacker-controlled "monitoring" code's runtime changes based on whether the DMP ran or not.

If that's right, then the attacker still needs to run their monitoring code on the target, it isn't sufficient to just run OpenSSL etc itself.

Edit: it is more explicit in the paper, they assume that OpenSSL (the victim) is still constant time:

> In this paper we assume a typical microarchitectural attack scenario, where the victim and attacker have two different processes co-located on the same machine.

> For our cryptographic attacks, we assume the attacker runs unprivileged code and is able to interact with the victim via nominal software interfaces, triggering it to perform private key operations. Next, we assume that the victim is constant-time software that does not exhibit any (known) microarchitectural side-channel leakage. Finally, we assume that the attacker and the victim do not share memory, but that the attacker can monitor any microarchitectural side channels available to it, e.g., cache latency.

[mort96]

Thanks for the details, I concluded more or less the same: https://news.ycombinator.com/item?id=39789307

[tsimionescu]

Because the timing difference is extraordinarily subtle, far too small to measure compared to regular network timing noise.

[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]

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.

[adrianN]

That usually just means that you need to collect more data to filter out the network noise.

[vbezhenar]

If you can collect enough data you can break any password just by trying.

"More data" might be not practical.

[eru]

Anything you execute on behalf of a user, even if the binaries are trusted, can effectively become untrusted code.