[Cryptography] Gates are cheap. Should cipher design change?

[Jerry Leichter]

> Maybe back to the original point, we want ciphers with huge, and
> preferably arbitary size blocks. A guy from Cisco made essentially the
> same point in his talk at the NIST lightweight crypto workshop so it's not
> just me and the people I work with. NIST/NSA public consumption ciphers
> seem to deliberately avoid large block sizes. The absence of 256 bit block
> sizes from AES and Simon/Speck is clearly deliberate. We want all the
> powers of 2 block sizes up to at least the size of the largest jumbo
> packets and the largest unit of disk block storage.
Funny you should say that.  I had remembered a cipher - described, I think, in Scheier's book - which allowed arbitrary (or at least highly variable) block sizes.  I couldn't remember the name nor find a reference (and I couldn't quickly get my hands on the book) so didn't mention in my message.

One can look at the evolution of machine-implemented ciphers as:  First we had stream ciphers, because they can be implemented with very limited hardware resources.  But stream ciphers have their own sets of issues, so about the time chips became available, we moved on to block ciphers.  DES was right at the edge of implementability when first proposed - the first DES implementations that could run at full Ethernet (10Mbps!) rates were significant breakthroughs.  Eventually, as we could use more resources, we moved from 64- to 128-bit blocks to deal with the very specific issue of the birthday paradox limiting the number of bytes that could be safely transferred.  And there we've stopped.

Now, one can argue about whether a larger block size, or simply implementing something like counter mode in hardware parallel, is the better way forward.  Worth thinking about, though.
                                                        -- Jerry