... Which leaves the question about why RC4_INT code was performing so poorly on P4 opened...
yeah i was meaning to go back and re-evaluate the RC4_INT case -- there's one thing i know really specific to rc4 which isn't a factor in AES: aliasing. iirc the rc4 loop has two table lookups and one table update, and there's a 1 in 256 probability of each lookup aliasing with an earlier update -- yielding about a 1 in 128 probability of store-forwarding violation because the processor has speculated the loads ahead of the store.
Yes, but whatever load misprediction penalties are, why would they be different for sparse and char tables? At least it's obvious that probability of misprediction is *exactly* same for RC4_INT and RC4_CHAR...
btw i might have a p4 like yours -- send me family/model/stepping... it's eax from cpuid level 1, or in /proc/cpuinfo on linux. i know i've got a model 0 here and i might have a model 1.
cpu family : 15 model : 2 stepping : 4 cpuid level : 2 # what's that? never mind...
fixing that is a more significant effort --
Not to mention that it can get constrained by possible FIPS certification: the code can end-up carved in stone as big-endian.
aha this i know nothing about -- where can i read up on FIPS certification restrictions / process?
There is ./fips catalog in 0.9.7 branch which is nominated for FIPS certification. There is no documentation yet, so that formal answer to the question is "nowhere." But anyhow... "Carved in stone" rather means "highly unlikely that someone would sponsor the change." In other words it's not actually a technological "obstacle," yet it's something to bear with... A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
