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 ?

  • the paper is from 2005. i think VMs, multi-core CPUs, and newer instruction sets make such attacks much more difficult than the rather favorable conditions outlined in the paper. – dandavis Jan 29 '17 at 22:26

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.