On Tue, Jun 30, 2020 at 5:29 AM Jeffrey Walton <noloa...@gmail.com> wrote:
>
> On Tue, Jun 30, 2020 at 5:14 AM Maamoun TK <maamoun...@googlemail.com> wrote:
> >
> > Patch implementation benchmark for GCM_AES (Tested on POWER8):
> > little-endian:
> > - Encrypt x~17.5 of nettle C implementation
> > - Decrypt x~17.5 of nettle C implementation
> > - Update x~30 of nettle C implementation
> > big-endian:
> > - Encrypt x~18.5 of nettle C implementation
> > - Decrypt x~18.5 of nettle C implementation
> > - Update x~28.5 of nettle C implementation
> ...
>
> One small comment for aes_encrypt and aes_decrypt... src and dst are
> usually user supplied buffers. Using lxvd2x to load a vector may
> produce incorrect results if the user is feeding a stream to an
> encryptor or decryptor that is not naturally aligned to that of an
> unsigned int. (On the other hand, Nettle controls the round keys array
> so lxvd2x should be fine.)
>
> Instead of lxvd2x and friends for the user's buffers you should
> consider using lvx and doing the lvsl thing to fix the data in the
> registers.
In fact, you might want to add a test case like this:
uint8_t plain[19] = {0,1, ..., 17, 18};
uint8_t cipher[16], recover[16];
Then send plain, plain+1, plain+2 and plain+3 into the encryptor and
see if it round trips. lxvd2x will choke even on POWER9 because two of
the tests will not even be naturally aligned for a byte.
Jeff
_______________________________________________
nettle-bugs mailing list
nettle-bugs@lists.lysator.liu.se
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
