On Thursday 11 December 2008 23:02:12 Huang Ying wrote: > On Fri, 2008-12-12 at 11:38 +0800, Geoff Thorpe wrote: > > The cipher and digest support is at the granularity of "nid"s, and > > these combine algorithm, key-length, and mode. So if you implement > > support for those cipher,length,mode combinations that can be > > accelerated by AES-NI, your engine will only be invoked for those > > combinations. You're not obliged to implement anything else, and > > indeed there is nothing to be gained by doing so. > > The situation is: > > - We implement cbc and ecb mode in engine > - If we implement cfb and ofb in engine too, we will duplicate code of > cfb and ofb mode itself. > - If we do not implement cfb and ofb in engine, no code duplication, > BUT we can NOT get AES-NI acceleration for AES core block algorithm > (which benefit cfb and ofb too) until we have a "branch" version.
OK, I (mis)understood from your original mail that you could only accelerate a subset of modes. If you can accelerate them all, then please do so by implementing an intel/aes-ni engine. But not by branching in the vanilla implementation. > So my suggestion is: > > - Accelerate AES core block algorithm with "branch" version. Which is > used by cbc, cfb and ofb too. > > - Accelerate AES ecb and ctr? with "engine" version. And my suggestion is: - write an engine for your hardware. It is my intention to eventually "engine"ify the "default s/w implementations" anyway - their static existence is a legacy thing that will get deprecated eventually (that way, if you don't want them and don't load them, or only load a subset of them, your linker and run-time footprint will shrink). At that point the whole issue of duplication is moot because someone will use the vanilla implementation *OR* your AES-NI engine, but not both. Even for now, the duplication issue is a red herring (especially when weighed against the inelegant mess it'll make of the code). So please, just write an engine and see how that goes. Cheers, Geoff -- Un terrien, c'est un singe avec des clefs de char... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
