[jjmarr]

Can an integrated CPU-FPGA design (like the ones AMD sells) be a solution to this problem? Point 5 of the paper says:

> Modern hardware and software stacks use a very layered structure, with each layer striving to hide its internal functioning details from upper layers. The socio-economic context which allowed such hardware to exist inherently relies on such abstraction (under the name of “industrial secrecy”). An effective constant-time coding process would require a model of computation with strong guarantees on timing-related characteristics, that would be maintained through all these layers, down to the semiconductors that implement the logic gates. This industry-wide vertical cooperation is unlikely to happen

It's not mentioned in the paper, but hardware description languages provide strong guarantees on timing-related characteristics on the semiconductor level. Hardware companies are willing to provide user access to FPGAs, as evidenced by the userspace FPGA subsystem in the Linux kernel as well.[1] You can buy Versal SOCs right now that combine ARM CPUs with FPGAs on one die, run Linux on it, and outsource your crypto tasks to the FPGA.

I see a future where we give up on constant-time coding for CPUs and move crypto libraries to FPGAs, given the hundreds of billions of dollars in our economy reliant on strong encryption. That'd be a world in which every corporate laptop is required to have an FPGA for compliance purposes.

It'd be interesting to know if anyone has tried this.

[1]https://www.phoronix.com/news/FPGA-User-Space-Interface-AMD

[NoahZuniga]

FPGAs are very expensive, so a TPU that implements the most important algorithms might be so much cheaper because the design cost can be amortized on the huge amount of required chips.

[jjmarr]

I believe the challenge that FPGAs can address is sociotechnical, because the developer of a crypto library will have much more control over the stack and does not need to trust others.

Many high-frequency trading companies use FPGAs over ASICs for similar reasons. FPGAs are more expensive but allow them to have full control over the algorithms implemented and doesn't require giving secret information to a foundry.

In other words, eliminate the impedance mismatch between responsibility and control for developing a secure system.

It'll be cheaper to implement cryptography on an ASIC. But the author of this paper wants to control every single aspect of the encryption/decryption process. Said developer can confidently say the system is secure. You can't say you've delivered a secure system if you're getting your ASICs from another company that doesn't provide implementation details because it'd (justifiably) give others a competitive advantage.

Question I'd have is whether the cost difference between ASICs/FPGAs is worth it for the majority of applications. $1 or $10 on every CPU might mean a world in which every laptop has an FPGA, but $100? What about for server-side applications? Would a hyperscaler spend $1000 extra on every rack if it allowed guaranteed constant-time encryption?

[burch45]

It’s not about “giving secret information to a foundry”. It’s entirely the field programmable (FP) feature. It’s also not really programmable in the sense that you would be sending in new instructions in realtime. Reconfigurable is a better word. So giving everyone an FPGA in their laptop isn’t really going help anyone in except some enthusiast who wants to try out some different algorithms.

[hinkley]

My impression is that there’s a lot of mental shorthand in the chip design community and FPGAs are used for prototyping and then translated into ASICs for any niche or larger applications. I presume there’s a pretty straightforward translation process between the two, though no one has ever tried to explain it to me.

[boothby]

A very simple description of an FPGA is that it's got a bunch of switches on the ends of wires. Some of the switches can connect wires to logic elements and some can connect wires to other wires. In this view, programming an FPGA is just toggling switches so that some of them are "on" and the rest are "off".

The easiest migration from FPGA to ASIC is to just make a chip with the same circuit elements and wire segments, but instead of making switches, you just short out connections in the "on" state and leave the rest open.

[pjc50]

The FPGA idea raises security questions of its own - how do you get the bitstream over securely, then the data and results, without leaking the data you're trying to protect or being vulnerable to evil clones of the bitstream? Or the FPGA debug JTAG interface?

Meanwhile Windows is requiring that every laptop have a small crypto processor for its own compliance processes (i.e. bitlocker).

[jjmarr]

I would assume the bitstream would only contain non-secret implementation details and keys would be loaded at runtime rather than being synthesized into the design.

In terms of moving the data over to the FPGA, I have no idea. But if it's all on the same die, it doesn't seem like there's a big physical attack surface that's different than just doing stuff on the CPU.

[hinkley]

I’m confused by the quoted text because timing attacks rely on at-most behavior and abstraction layers on at-least behavior.

Abstractions cannot send messages before they receive them. So any delay you add at the top must be magnified as you go down. The exception to this is if the contents of the message require different behaviors for different payloads, in which case they are correct. But encrypted payloads are opaque to the layers they are sent through. You can observe who the message was sent to, and know the maximum amount of data the conversation might have contained. But not a very clear idea of how long it took to build the message, unless you’ve already compromised the machine.

[manwe150]

Recent timing attacks rely on the observation that modern CPUs send some messages faster than other messages, based on predicting what they might contain, so some delays get magnified (those that deviate from expectations) while other delays (those that match prior data) get minimized as you go down. An encrypted payload leaks this same information too (the process is independent of what data is being transferred), although that leaked information is (hopefully) not useful since it just leaks the encrypted data, which (hopefully) looks like random noise. But that data has to be encrypted and decrypted at some point somewhere, which gives a point to attack.