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]
