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.
Not that I'm answering the question with a question, but what's wrong
with movups? I mean I consider that the question about copying key
schedule was already discussed in enough detail, but I'm left with
feeling that other options are even less preferable. So I wonder why? Is
movups expected to so much worse? Even if input is "moderately"
misaligned, say at 64-bit boundary instead of 128? Can't one pipe-line
it, i.e. schedule movups longer before aes[enc|dec], to "amortize'
additional latency, or will it be non-pipe-line-able? Even if so, it's
possible to compromise having movaps and palignr. If one chooses to
declare key schedule to ensure 64-bit alignment(*) it would really have
to be a single palignr case... A.
(*) for example see
http://cvs.openssl.org/fileview?f=openssl/crypto/camellia/camellia.h&v=1.4.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majord...@openssl.org
