check for SSE bit instead of MMX, as pshufw was introduces in PIII, minor
optimization, typos...

256 byte S-box. AES_cbc_encrypt needs further work as it should also use
slow routines when processing smaller amount of data.

strong impact on decrypt performance, 20-25%. One probably should consider
switching between slower and faster routines depending on how much data
we were asked to process.

only chance for T[ed]4 to get evicted in this module is when its cache
"overlaps" with last 128 bits of key schedule.

prefetch could have been moved closer to Td4 references. Something for
later consideration...

debugging and doesn't affect functionality.

Submitted by: David Mosberger

Obtained from: http://www.hpl.hp.com/research/linux/crypto/

aligning the key schedule in a specific manner.

PR: 1059

compressed tables (2x compression factor) and by pre-fetching them into
processor cache prior every CBC en-/decryption pass. One can argue why
just CBC? Well, it's commonly used mode in real-life applications and
API allows us to amortize the prefetch costs for larger data chunks...

hand-coded zero-copy AES_cbc_encrypt.

performance on recent microarchitectures.

C code yet...