[ksayhtrc] block cipher of width 384 bits

when using a block cipher in counter mode, we desire a block size of at least 384 bits.  choose 256 bits of initialization vector (nonce) randomly plus a 128 bit block counter.  at those sizes, it is unlikely that nonces will collide, and it is similarly infeasible to overflow the block counter.

inspired by AES Galois Counter Mode with its 96-bit IV and 32-bit block counter (needing to fit in a 128-bit AES block).  security catastrophically fails if you use the same IV more than once, or if the block counter wraps around.  probability of accidental misuse seems high.  the block counter will overflow, perhaps silently wrap around, at 64 gibibytes of data, a realistic amount of data to transmit these days.  if you use a time-based approach for IV, your clock may have run out of battery and reset to a time close to 0.  if you use any non-random method for IV generation, you need to avoid leaking information in the IV (future post: qqsojkvx).

CTR mode (though not GCM) was well known when AES was selected.  what were they thinking when they nixed Rijndael's 256-bit block size option?  256 bits is not ideal, but 171 bit random IV and 85 bit block counter are probably good enough (in the same line of thought that 160-bit hashes (SHA-1) and 80-bit ciphers (Skipjack) are probably good enough).

similarly, it's surprising that 256-bit Rijndael hasn't been added to AES in the intervening years.

for 256-bit block cipher, if IV is chosen randomly, then having the block counter simply increment IV seems OK, using the entire 256-bit block as IV.  but bad things can happen if IV is not random: some increment of an IV of one message can collide with IV of another message.

if performance is no concern, then you can build your own good large block cipher out of good existing components with the Feistel network, e.g., NIST SP 800-38G Format Preserving Encryption, or Keccak (future post: osjepxqx).  but beware building your own crypto.

some large block ciphers were mentioned previously.  additional commentary:

XSalsa20 (not a block cipher) has a 192-bit nonce (good enough) and 64-bit block counter (worryingly small).  can XSalsa20 be augmented to provide authenticated encryption in the style of GCM?  it's probably not too difficult to make the nonce slightly smaller and block counter slightly larger.

XXTEA permits larger blocks, but maybe you want to bump up the number of rounds.  its known vulnerability is at huge block sizes (1696 bits), far beyond the 384 bits we want.

once you've selected a large block cipher, you'll need to fix up GCM because it assumes a 128-bit block.