<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den sön 18 juli 2021 01:19Jon Callas <<a href="mailto:jon@callas.org">jon@callas.org</a>> skrev:</div></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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. <br>
<br>
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.)<br>
<br>
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. <br>
<br>
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.<br>
<br>
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. <<a href="https://www.cs.ucdavis.edu/~rogaway/aez/rae.pdf" rel="noreferrer noreferrer" target="_blank">https://www.cs.ucdavis.edu/~rogaway/aez/rae.pdf</a>> (AEZ itself  is a completely different discussion, and beyond the scope of the already-too-much I've said.)<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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. </div><div dir="auto"><br></div><div dir="auto">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.)</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>