On Thu, 2008-12-11 at 23:03 +0800, Geoff Thorpe wrote: > On Thursday 11 December 2008 05:04:36 Peter Waltenberg wrote: > > Anything in memory could end up swapped out, but stack is the least > > likely since it's more often in use, the best you can do is zero the > > area ASAP. > > > > My other objection to putting all of this into an engine is that the > > engine code is unusable in quite a few cases. Export approvals, and > > certifications like FIPS and Common Criteria all pretty much insist > > that the crypto. isn't replaceable by some random chunk of code, > > that's not an OpenSSL issue as such, but it's going to be awkward for > > some subset of OpenSSL consumers. There are ways around those issues, > > but I doubt you really want to add the option of signature checking > > engine plugins ?. > > Engines like eng_cryptodev.c *are* built in (they're in ./crypto/engine/ > rather ./engines/) and the intention is that they should be the > implementation "de base" for those build targets to which they apply. > Cryptodev is the only one so far, but there could be others. In fact, > the padlock support for VIA chips (which is comparable to what's being > discussed here, with all due respect to the intel instruction-set > faithful) sits in ./engines like any other h/w support - a similar > argument could be made that, on chips that support it, it should provide > the default implementation(s), but right now they've been happy enough > to make it a non-default option.
The difference between Intel AES-NI and padlock is that padlock provide support for different modes directly including ecb, cbc, cfb and ofb, while Intel AES-NI just provides instructions for AES core block algorithm NOT for modes directly. At the same time, AES-NI pipelining implementation can benefit ecb encrypt and cbc decrypt and counter mode. If we implement AES-NI with "branch", we can get full power of AES-NI except ecb and ctr mode. If we implement AES-NI with "engine", we can get full power of AES-NI for all modes. But we must duplicate mode implementations that can not benefit from AES-NI, such as cfb, ofb, etc. Do you OK with code duplication? So I think the best method is to implement AES-NI with both "branch" and "engine". With branch version, we get full power of AES-NI for cbc, cfb and ofb mode. At the same time the engine version can provide further acceleration for ecb and ctr mode. Best Regards, Huang Ying
signature.asc
Description: This is a digitally signed message part
