On Wed, 2008-12-10 at 15:56 +0800, Andy Polyakov wrote: > >> - "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."
In engine, I can just just re-align the expanded key address because it
is not exposed to user? Something as follow:
typedef struct
{
AES_KEY ks;
unsigned int _pad[3];
} INTEL_AES_KEY;
IMPLEMENT_BLOCK_CIPHER(intel_aes_128, ks, intel_AES, INTEL_AES_KEY,
NID_aes_128, 16, 16, 16, 128,
0, intel_aes_init_key, NULL,
EVP_CIPHER_set_asn1_iv,
EVP_CIPHER_get_asn1_iv,
NULL)
BTW: The comments of AES_KEY in aes.h says:
/* This should be a hidden type, but EVP requires that the size be
known */
Does this means AES_KEY is not a public interface and user should not
take use of its internal implementation?
> >> - 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."
ECB, CBC decrypt, CTR can benefit from AES-NI pipelining. But other
modes can not. So maybe we should have both "branch" version and
"engine" version. "Branch" version used for other modes and CBC decrypt,
while "engine" version used for "ECB" and "CTR" modes.
BTW: Is ECB used widely in practice?
Best Regards,
Huang Ying
signature.asc
Description: This is a digitally signed message part
