On Tue, 2008-12-16 at 21:30 +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. > > 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.
That sounds interesting. At least deserve try. Best Regards, Huang Ying
signature.asc
Description: This is a digitally signed message part
