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.

those referencing compact, 256-byte, S-boxes.

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...

eay licence, as module is practically rewritten from scratch [well,
even original submission was obviously "almost, but not quite,
entirely unlike" any other eay *_cfb.c module, not to mention new
functions].

platform to platform. Its absolute value is within few percents
marginal from that of ECB.

of bits; thanks to Michael McDougall <mmcdouga@saul.cis.upenn.edu>

PR: 1318

space, but gives total flexibility [back].

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.

[most importantly] put back dependencies accidentaly eliminated in
check-in #13342.

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...