On Thu, Jan 4, 2018 at 2:15 PM, Niels Möller <[email protected]> wrote: > 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?
I wouldn't expect if anyone uses 3des in CTR mode, but I wouldn't be surprised by it either. What about introducing ctr_crypt128() and having it used by CCM, and EAX? (it seems gcm is not using it anyway) regards, Nikos _______________________________________________ nettle-bugs mailing list [email protected] http://lists.lysator.liu.se/mailman/listinfo/nettle-bugs
