I think it's overly paranoid :). No other keys are protected in that way.
Also: If mlock()'d memory isn't automatically free'd when a process crashes
you risk DOS'ing the OS eventually as well. (I'm not sure whether that's
the case or not, just a vague memory from the past.).
I'd certainly prefer the code in the core, with extended function as an
engine.
Steve Marquess described the problem with certification and engines pretty
well, give the certifiers anything they can complain about and the process
gets 10x harder/slower, it's a lot easier if we can have a clean "we don't
do that" statement.
Peter
From: Huang Ying <ying.hu...@intel.com>
To: "openssl-dev@openssl.org" <openssl-dev@openssl.org>
Date: 12/12/2008 11:47
Subject: Re: [PATCH RFC] Add support to Intel AES-NI instruction set for
x86_64 platform
On Thu, 2008-12-11 at 18:04 +0800, 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.
At least on UNIX system, mlock() can be used to prevent specified memory
range from swapping out. Maybe we should put all key schedule into a
memory area protected by mlock()? That is safer than stack I think.
Best Regards,
Huang Ying
> 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 <ying.hu...@intel.com>
>
> 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 majord...@openssl.org
[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 majord...@openssl.org
