What are mitigation techniques against Cache-timing attacks on AES?

Question

I read here a paper of Daniel Bernstein

This paper demonstrate complete AES key recovery from known-plaintext timing of a network server of another computer. This attack should be blamed on the AES design not on the particular AES library used by the server. It is extremely difficult to write constant-time high-speed AES software for common general-purpose computers

There is countermeasures for new processors and architectures ?
Why is so o write constant-time high-speed AES software for common general-purpose computers ? What is the problem ?

Answer 1

It's not that creating a constant time implementation is inherently problematic, it's mostly a matter of efficiency and awareness.

The table based implementations are fast. Constant time implementations are possible, but tend to come at the cost of reduced performance compared to the table based version.

Additionally, and the more likely culprit, is the awareness level of the implementer of the existence of cache timing attacks. This is not something that is immediately obvious to the uninitiated. Implementations that are constant time are generally not so by accident - they were written that way with explicit intention by the implementer. A good example is bearssl.

Lastly, many modern CPUs have the AES-NI instruction set, which basically offloads the AES computation to a dedicated hardware circuit, and should run in constant time.