113 bytes is extracting an AES key from memory in about a minute.

How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else?

That's what really irritates me about all these side-channels that have been found ever since the first Spectre/Meltdown --- they all demonstrate something flashy like "we read a key/password/secret/something important from memory in a few minutes" while conveniently ignoring to mention the countless hours spent aligning everything just right so they could show off the one "magic trick". In a lot of the cases there's barely even any control over where it reads.

Every time something like this comes up, I feel compelled to post some bytes from somewhere random in the memory of a random process on my machine to show just how much I care; here you go:

    E8 7F 00 00 00 A1 64 30 40 00 89 45 D8 8D 45 D8
    C4 20 00 00-CE 20 00 00-D8 20 00 00-E2 20 00 00
    F8 20 00 00-00 21 00 00-0E 21 00 00-16 21 00 00
    26 21 00 00-36 21 00 00-42 21 00 00-56 21 00 00
    66 21 00 00-76 21 00 00-84 21 00 00-96 21 00 00
    AA 21 00 00-00 00 00 00-FF FF FF FF-B4 16 40 00
    C8 16 40 00-7C 20 00 00-00 00 00 00-00 00 00 00
    EC 20 00 00-00 20 00 00-00 00 00 00-00 00 00 00

Of course if you are being targeted then the concern may go up, but I still think that attackers would have lower-hanging-fruit than this, seeing as setting up one of these reads to get one secret would itself require such intimate knowledge of your machine's configuration and state that they probably already know what they want.

> How do you know where the key is, and how are you guaranteed to be able to read enough of it before the "shifting sands" that is timing unpredictability and general noise in the system make you read something else?

I don't mean to understate the difficulty of the task, but I've also seen probably tens of repros by now that use intimate knowledge of e.g. the kernel page allocator and known post-boot state of e.g. a firmware image flashed on millions of devices to drastically cut down the search space

What is it that programmers do? They automate complex tasks that take humans considerable effort.

If a university can accomplish this task with their funding and no urgent incentive, what is the nation state actor doing with their enormous budget?

The conventional wisdom is that if a nation state wants your data badly enough it is game over. Even an air gap can apparently be bridged if you have the budget and you're patient and smart enough. It's root kits, booters, ransomware, exfiltration and script kiddies that you have to worry about in practice.

It's not what a nation does to it's own supply chain that a nations supply chain has to worry about.

Yes, and the point is how do we define "badly enough".

Badly enough as in they can ever do it a few times a year against a few high-value targets, or badly enough that they can do it to "only" a few tens of millions a year?

Even end-to-end encrypted communications can be bypassed if the government wants them "badly enough". But the point is that with E2E encryption, they can no longer tap into and data mine the conversions of billions in real-time to fish for crimes.

Just like when fighting malware creators, the point of security is to keep raising the standards and the difficulty for the malicious actors.

> while conveniently ignoring to mention the countless hours spent aligning everything just right

It's really not that hard. E.g. people working on browser exploits have been working on exactly this for years and years, back when just having an out-of-bounds read due to a regular browser bug was the mechanism. Turns out that programs are absolutely chock full of pointers and it doesn't take long to run across one that points to what you are looking for. Especially because programs tend to have lots of data structures that end up pointing to more and more important data structures, funneling you into the guts of the program.

Sure, reverse engineering takes work, but blindly hunting in memory with no clue it is definitely not.

Side-channel attacks are basically a persistent out-of-bounds read mechanism. That is a very bad thing (TM).

There are literally thousands of people who work on this day in and day out, and millions in bug bounty programs out there.

what's your opinion on package management communications? couldn't an eavesdropper on the network deduce quite a bit about your system's configuration? distribution of dates and sizes of packages downloaded seems like quite a leak.

perhaps package servers and package management software should round up the package size to hide the identity of the package? use oblivious transfer to hide the identity of the package from the package server itself?

History has repeatedly shown that "infeasible" attacks are really just difficult.

>but the instant it's in a rootkit everybody will be able to do it.

This makes no sense. If you have the privileges to install a rootkit, there is no need to use any speculative execution exploit.

The first feature of a rootkit is to get root access. A userspace kernel-information leak utility would be very useful for this step.

Okay, we have differing definitions of what a rootkit is it seems.

They mean in the implementation of a rootkit.

we have yet to even find Specter in a kit, this will never see the light of day, especially since it is so easy to avoid (turn TSX off).

You also, don't get to extract constantly. You only get a shot when the data is in the LFB, so the program needs to be actively reading or writing it to keep it moving back and forth from L1 and L2, at least that is the way I read the paper.