This is rather a theme for NIST selected algorithms. AES
includes a number of operations on a binary field and CPUs
generally don't implement binary field operations because they
aren't really useful for anything else. So many software
implementations of AES include four, 1024-byte tables of results
in that field in order to achieve reasonable performance.
However, these table lookups cause a timing side-channel which
is fairly effective even over a network. On the same machine,
where the CPU cache state can be probed more directly, it's very
effective. In response to this, some AES implementations made
their tables smaller to reduce the leak. That's obviously an
improvement, but it came at the cost of slowing AES down and AES
was never very quick to start off with. And while a smaller leak
is better, AES is supposed to be operating at (at least) an
128-bit security level! Next, the mode recommended for AES by
NIST is GCM: it's AES in counter mode coupled with a polynomial
authenticator. Cryptographically thi