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 ?. Perhaps a compromise ?. Put the generic AES speedup into the core, and the extra modes where you gain the big performance boosts into an engine ?. Peter From: Huang Ying <[EMAIL PROTECTED]> To: "openssl-dev@openssl.org" <openssl-dev@openssl.org> Date: 12/11/2008 05:06 PM Subject: Re: [PATCH RFC] Add support to Intel AES-NI instruction set for x86_64 platform On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote: > Implementation aiming to complement interface exposed by crypto/aes/asm > should allow for non-16-byte-aligned key schedule. Period. One can use > movups, or check alignment and choose between movups and movaps code > paths, or copy key schedule to aligned location on stack. Should it be considered an unsafe behavior to copy key schedule to stack? The stack maybe swapped out to a swap file, so that the key schedule is leaked. Best Regards, Huang Ying [attachment "signature.asc" deleted by Peter Waltenberg/Australia/IBM] ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]