[Cryptography] Recommended Process for a new cipher mode submission

[Natanael]

Den sön 18 juli 2021 01:19Jon Callas <jon at callas.org> skrev:

>
> Having said that, however, there is at least one thing that would be
> really good to have: tweakable ciphers. A tweak is the generalization of an
> IV/counter/nonce, and there are a lot of mode issues that go away if you
> have tweaks in the cipher. A tweakable cipher is secure even when the tweak
> is under attacker control. It collapses a lot of discussion about modes.
>
> You really only need a generalized counter, which is perhaps a glib thing
> to say. Nonetheless, if you generalize a counter to include increment by
> any given constant, or something extended like the cipher text of block $i$
> becomes the tweak of block $i+1$ (which is the tweak-analogue of CBC), you
> don't need anything else. (And moreover, in the tweakable system, tweak-CBC
> is no more cipher-secure than a simple counter; it is, however, not
> parallizeable, which is either a flaw or a feature depending on what
> problem you want to solve.) (Additional note, tweak-counter is not the same
> thing as CTR mode. CTR mode is a stream cipher and suffers from all the
> stream cipher problems of key reuse letting you learn the underlying
> keystream, etc.; tweak-counter is chaining.)
>
> The other major thing worth having is a wide-block block cipher. 1024bits
> (128 bytes) is good enough, I'd really like to have 4Kbits (512 bytes).
> Variable block size would even be cooler, as would a pony. The reason for
> the wide block is that it better approximates an idealized all-or-nothing
> transform. The wider a block is, the less some weaknesses matter. For
> example, with present 128-bit block ciphers, ECB mode easily leaks minor
> things. It isn't unreasonable, for example, for a data structure to have 16
> bytes of zeroes. There are also lots of places where there are related
> issues -- many, many XML files start with "<?xml version="1.0"
> encoding="utf-8"?>" which is 38 bytes long. This is far less if a problem
> the wider the block is. The real solution is to use tweak-counter on your
> wide block.
>
> For those who are going to stress over sizes and padding, there are two
> viable answers. The best in my opinion is to let an upper layer worry about
> exact length. This really does work: every disk file system for as long as
> there have been disks has had to deal with this -- and they were dealing
> with blocks of 512 bytes! For those still stressing, it's easy to take your
> final block and make a tweak-cipertext-stealing analogue. This is really
> only taking a convenient ciphertext and XORing it onto that last block. You
> can fill out the specifics as well as I can. I also leave the
> tweak-analogue of CMAC/OMAC as an exercise for the reader. My final comment
> is that the astute reader will note that I've just been saying, "go ahead,
> roll your own crypto! Knock yourself out!" That's how good tweakable
> ciphers are to have.
>
> For further reading on why this is what we really need, the paper, "Robust
> Authenticated Encryption" by Hoang, Krovetz, and Rogaway is absolutely the
> bomb. It's the theory paper for the "AEZ" construction that takes AES
> round-function primitives to make a variable width, large-block, tweakable
> cipher. <https://www.cs.ucdavis.edu/~rogaway/aez/rae.pdf> (AEZ itself  is
> a completely different discussion, and beyond the scope of the
> already-too-much I've said.)
>

I have a handful of "pet ideas" for cipher system constructions which align
with these comments. A few for the sake of robustness, a few for reducing
latency or otherwise increasing performance.

One of them is a mode using a tweakable cipher using a pseudorandom counter
input, applying the most lightweight viable permutation on a plain counter.
Note that this is efficiently parallellizable, especially in hardware where
you can pipeline this so that the extra permutation do not add any latency
at all.

Another includes using large structured tweak inputs and caching
initialization midstate (for latency reduction), so that you for example
can use the tweak input both as a domain separator and simultaneously
efficiently use it as a counter input. Like say you put a database entry ID
in the tweak, along with a block counter, and then cache the midstate so
you don't need to process the ID repeatedly for every block of that
database entry.

Yet another is one that has been done (also similar to idea #1 above), but
which I want to see more efficient constructions for - a block cipher where
the keys for each subsequent block are subsequent outputs from a stream
cipher. The Enchilada cipher does this, but i want to see this done based
on a lightweight permutation used both for the block cipher component and
for implementing the stream cipher. (If done with a tweakable cipher, the
tweak can contain the IV and context / domain separation data, etc.)

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210718/9a208efa/attachment.htm>