On Wed, 2008-12-10 at 03:40 +0800, Andy Polyakov wrote: > As for RFC part. NO! This is NOT the way to do it. For several reasons > (in ascending order of importance): > > - OpenSSL assembler modules are maintained as dual-ABI, i.e. suitable > for both Unix and Win64;
OK. I will follow the way like that in aes-x86_64.pl to deal with ABI
issue.
> - "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?
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)));
And how to deal with memory allocated with malloc()?
> - zero-copy CBC routine gives a fair performance improvement even in
> ordinary case, and driving ultra-fast block function from C would be
> just wasteful. In other words AESENC/DEC would benefit more from
> dedicated CBC routine (see even comment below);
I will do more investigation on that.
> - 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. 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.
> > This patch adds support to Intel AES-NI instruction set for x86_64
> > platform.
> >
> > Intel AES-NI is a new set of Single Instruction Multiple Data (SIMD)
> > instructions that are going to be introduced in the next generation of
> > Intel processor, as of 2009.
>
> Hardware however is not expected before 2010, right? A.
Maybe 2009 or 2010, I don't know that exactly too.
Best Regards,
Huang Ying
signature.asc
Description: This is a digitally signed message part
