- "and $-16, %rdx" is unacceptable in this context. The relevant
interface is exposed to end-user and we have to reserve for possibility
that key schedule is memcpy-ed to location with alternative alignment;
Does there any other mechanism to deal with alignment issue in OpenSSL?
"The answer is engine."
Is it better to declare AES_KEY as follow:
struct aes_key_st {
unsigned int rd_key[4 *(AES_MAXNR + 1)];
int rounds;
} __attribute__ ((aligned (16)));
This is gcc-ism and we support other compilers, so no.
And how to deal with memory allocated with malloc()?
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.
- implementation should allow for pipelining;
As for the latter. I refer to possibility of scheduling of multiple
AESENC/DEC with same key schedule element and multiple data chunks. It's
possible in modes that allow for parallelization (e.g. ECB, CBC decrypt,
CTR), and as far as I understand it is even recommended. So we are kind
of obliged to reserve for this option.
The answer is engine. I mean this preferably should be implemented as
engine that will be able to take full advantage of architecture, not as
patch to general purpose block function.
But as Peter Waltenberg said, engine has its issue too.
Yes, and the relevant question is if it worth it.
At least we
should have a "branch" based version (may be slower) to benefit most
users, until we can make engine version usable by most users.
There is no hardware in sight, so "until" is not really an argument. One
can reserve for "branch" version as back-up/exit plan, i.e. "in case,"
but not "until." A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
