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. In any case, the solution is not to say "nah, that's not quite what I need - I'd rather patch into the default s/w implementation instead and disable engine support". The "default s/w implementation" is a legacy notion maintained for backward compatibility (in an ideal world, that would be an engine too, in fact it would be multiple engines - asm, no-asm, [etc]...) The issues of signatures and dynamic loading are questions of build configuration, which distinguish between what is (a) built in to the libcrypto image and registered/enabled by ENGINE_load_builtin_engines(), and (b) possibly external to libcrypto and must be explicitly enabled/loaded. If you have issues with those semantics (and I know of a few, but fixing and simplifying them will require deprecating the notion of "s/w fallback"), then patches to crypto/engine/ are welcome (as they would be for ./Configure). 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 [EMAIL PROTECTED]
