Slow side-channel free AES fallback

[dsprenkels]

In the Go standard library, there are a lot of different optimized implementations for AES. However, the fallback implementation is still a T-tables based implementation, vulnerable to cache timing attacks. There is a long-standing issue in golang/go asking to solve this: golang/go#13795

Although these vulnerable implementations should almost never be selected, it seems that they might sometimes be selected. For example, if the AES intrinsics are missing on Intel, the code seems to select a vulnerable key-expansion.

The solution to this would likely result in an AES implementation that is a lot slower, but I think this is preferable to an implementation that is insecure according to modern crypto engineering standards. In any case, most of the time Go will be able to use an optimized implementation anyway.

Goal

Provide a side-channel resistant replacement for encryptBlock and decryptBlock and expandKeyGo.

Ideas

To replace encryptBlock and decryptBlock, a {16x/24x/32x} bitsliced implementation would be straightforward for AES{128/192/256}. I am thinking, can we maybe do better in the AES128 case? (Parallelizing over multiple blocks is not possible with the current API.)

• Prioritize readability and simplicity over performance.
  • One function should implement all AES variants.
  • Implementation should be single block-based.
• [key schedule] Try a scanning-lookup-table approach for SubWord?

[armfazh]

Previous work on ARM/NEON by Fujii

[armfazh]

@hayatofujii would you like to collaborate on this?