Nikos Mavrogiannopoulos <[email protected]> writes:
> If I had to chose between optimizing one of two, I'd say CTR.
I agree CTR seems more important. I'm guessing that the loop
for (p = dst, left = length;
left >= block_size;
left -= block_size, p += block_size)
{
memcpy (p, ctr, block_size);
INCREMENT(block_size, ctr);
}
in ctr_crypt contribudes quite a few cycles per byte. It would be faster
to use an always word-aligned area, and do the copying and incrementing
using word operations (and final byteswap when running on a
little-endian platform), and with no intermediate stores.
Would be a pretty simple routine (maybe we don't even need to go to
assembly) if we require that the block size is a multiple of
sizeof(unsigned long), and even simpler if we restrict to block size 16.
But uglier and less efficient, if it needs to support the general case.
Maybe we could have a special case for blocksize 16, and accept that
unusual blocksizes will be much slower. Or could we drop support for all
but the most relevant block sizes here?
Regards,
/Niels
--
Niels Möller. PGP-encrypted email is preferred. Keyid 368C6677.
Internet email is subject to wholesale government surveillance.
_______________________________________________
nettle-bugs mailing list
[email protected]
http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
