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
Description: This is a digitally signed message part

Reply via email to