You were almost certainly benchmarking an implementation of AES that relies on table lookups for speed; those table lookups create a side channel vulnerability, which was much of the point of this article.

Interesting; it was what's in the Linux kernel.

Pretty sure that's an S-box AES. The issue is that when implemented (a) in software (b) without reliance on large lookup tables --- ie, "securely" --- AES is significantly slower.

That's a table of stream ciphers benchmarked against AES, a block cipher, in CTR mode.

Yes. Apart from disk encryption, they are pretty much interchangeable (OP talked about IPSec).

AES is normally benchmarked against other block ciphers. It might not be fair to compare the performance of a native stream cipher to that of AES rigged up as a stream cipher with CTR.

What makes the comparison unfair?

The other ciphers are natively stream ciphers, and AES is a block cipher adapted via CTR mode to be a stream cipher.

I'm still missing what makes it unfair. Are other modes of AES potentially faster? Does AES provide something that stream ciphers don't? Are Salsa20/Chacha20 unable to be compared to anything because they're native stream ciphers that look like a block cipher in CTR mode under the hood?

1. Yes. 2. Yes. 3. No.