Andy Polyakov wrote:
... padlock_aes_cipher(... const uint8_t *in_arg,...) { ... if (in_arg_aligned) { in = (uint8_t*)in_arg; if (out_arg_aligned) out = out_arg; else out = in;
Last line is no good. in_arg is declared const and is not expected to be modified. This is of course unfortunate, but you can't take advantage of the fact that input buffer happens to be aligned.
I see. Hmm. So in this case I'll run the realignment loop as well.
Throw in pushfl;popfl; at the end of padlock_aes_init_key. This would be required if we try to optimize pushfl;popfl; in padlock_aes_cipher, but we can as well do it now.
I wouldn't do it. Say that you first initialize two contexts with two keys and then use them concurrently. You must force key reloading whenever the other context is to be used, not while it is being created.
Have you considered to rearrange switch and loop in padlock_aes_cipher? I mean right now you have switch in loop, while you could have loop for every case in switch. It might make difference to performance...
Do you mean "quadruplicating" the realigner code for each case? Or take it to a separate function? I believe that this simple switch with four cases and inlined xcrypt functions can be very well optimized by the compiler. I will probably only put the 'mode' to a variable in advance to avoid dereferrencing ctx every time...
Can you explain what's the deal with IV? I don't quite undestand why do you save EAX value after xscrypt and use at as a pointer. Where does it point at exit? The way I understand the manual you simply can't rely on value in EAX being preseved and I can't see that it's meaningful after xcrypt...
As I understand it: when you have a large buffer that should be encrypted in (say) CBC mode and you encrypt it "per partes" (e.g. because of the limited-size realign buffer), you need to save the current IV at the end of each round to can to continue with the next piece. IIRC in all modes but ECB the IV is different after every basic block (i.e. 16 bytes in case of AES) is encrypted. That's why it has to be saved. (and it doesn't work without saving anyway :-)
What's padlock_cipher_data->key for? It only pollutes the cache... You can as well padlock_cipher_data->ks.rd_key, can't you? A.
Yes I can. I hope the AES_KEY structure won't be modified, especially that rd_key will always be the first item. Otherwise the alignment will break.
Michal Ludvig ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
