<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Mar 20, 2021 at 9:11 PM John Denker via cryptography <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/19/21 9:38 AM, Phillip Hallam-Baker wrote:<br>
<br>
> I started to think that maybe we have got to the<br>
> point where we should move past the 128 bit block size of AES.<br>
<br>
> The obvious replacement choice is 256 bits.<br>
<br>
===============<br><br>
3) Block chaining modes are IMHO a fig leaf, used to cover up<br>
 the ugliness of non-agile keying. It allows a key to be re-used<br>
 from one block to another. In contrast, IMHO a proper cryptosystem<br>
 simply uses a different key for each block. It does not require<br>
 an expensive "key-scheduling" step, and it is not vulnerable to<br>
 related-key attacks.<br>
<br>
 Many well-known ciphers have expensive key-scheduling and/or<br>
 related-key issues.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">What I am looking at is ways to tune a cipher so that I can use frequent rekeying of the </div><div class="gmail_default" style="font-size:small">symmetric key to avoid the need to go through an expensive public key agreement.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Rekeying on every block is a bad idea. Rekeying the symmetric cipher between each </div><div class="gmail_default" style="font-size:small">frame of video is a very different proposition because I can do that in parallel and</div><div class="gmail_default" style="font-size:small">it costs me nothing.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Lets say I am using AES-OCB for encryption and the initial 16 bytes of each packet contain:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Unique stream identifier  (24 bits)</div><div class="gmail_default" style="font-size:small">* Unique sequence number of frame within stream (32 bits)</div><div class="gmail_default" style="font-size:small">* Unique sequence of packet within frame identifier (7 bits)</div><div class="gmail_default" style="font-size:small">* Wibble bit (1 bit)</div><div class="gmail_default" style="font-size:small">* Bitmapped field acknowledging packets sent (56 bits)</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">These are not the QUIC values, assume I know what I am doing though.</div><br></div><div><div class="gmail_default" style="font-size:small">The end goal here is to be able to process an entire video frame and send it in one chunk so </div><div class="gmail_default" style="font-size:small">that it can be encrypted/decrypted as one unit</div><br></div><div><div class="gmail_default" style="font-size:small">I was asking about block size for several reasons:</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* Security</div><div class="gmail_default" style="font-size:small">* Performance</div><div class="gmail_default" style="font-size:small">* Should I build for a 16 or 32 bit initial block?</div><br></div><div><div class="gmail_default" style="font-size:small">My plan is to encrypt the first block of the packet in ECB mode using a key that is fixed for </div><div class="gmail_default" style="font-size:small">the lifetime of the connection. Note that NONE of the information in this field is confidential</div><div class="gmail_default" style="font-size:small">as far as the application is concerned. But why give any information out to traffic analysis </div><div class="gmail_default" style="font-size:small">when we don't need to?</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">An all zero first block means that the packet is an initial key agreement packet. All zero first </div><div class="gmail_default" style="font-size:small">blocks are avoided by decrypting the all zeros ciphertext and setting the wibble bit so it is</div><div class="gmail_default" style="font-size:small">never emitted.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
4) Key size is not the same as block size. PHB is AFAICT mostly<br>
 arguing for a 256 bit key, which is fine with me. In contrast,<br>
 I have yet to hear a persuasive argument for a 256-bit block,<br>
 or any block at all.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">When PHB says block size, he almost certainly means block size. I am not confusing it </div><div class="gmail_default" style="font-size:small">with key size because I only use 256 bit keys. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">At this point it seems reasonably clear that 256bit blocks is a long term prospect at best, </div><div class="gmail_default" style="font-size:small">it will be a decade at least before we have a NIST or similar standard.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">So that just leaves performance. And that could be the deciding factor because AES is a </div><div class="gmail_default" style="font-size:small">32 bit cipher in a 64 bit world. Processing my video pages using 256 bit blocks might well </div><div class="gmail_default" style="font-size:small">allow me to do so twice as fast given equivalent optimization.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The approach I am thinking of has the sender and receiver pre-allocating large buffers that </div><div class="gmail_default" style="font-size:small">are large enough to hold a full frame of video in compressed form. (They are going to need</div><div class="gmail_default" style="font-size:small">to hold a full frame of uncompressed at some point in the pipeline, so this should not be </div><div class="gmail_default" style="font-size:small">prohibitive).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Assuming 4K, 30fps video at 16,000 Kb/s, that is ~70KB per frame which is about 60 </div><div class="gmail_default" style="font-size:small">packets.</div><div class="gmail_default" style="font-size:small"><br></div></div><div class="gmail_default" style="font-size:small">So the idea here is to design the crypto framing so that I can precalculate the OCB tables</div><div class="gmail_default" style="font-size:small">before the frame is sent and I can optimize the packet layout so I can word align data for fast</div><div class="gmail_default" style="font-size:small">processing. The aim here being to avoid the need to copy data. I get my series of ciphertext </div><div class="gmail_default" style="font-size:small">blocks, and write the outputs to the corresponding place in the plaintext buffer. I only attempt</div><div class="gmail_default" style="font-size:small">decompression if the auth tag checks out.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The objective here is to limit lag to no more than two or three frames and try to make it </div><div class="gmail_default" style="font-size:small">one frame or less.</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> Example #3: Block chaining modes are dead on arrival if we need<br>
 to do random access.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">OCB can be configured so it can be used in the same manner as ECB (i.e. random lookup)</div><div class="gmail_default" style="font-size:small">but with a performance penalty for each 'seek' operation. And you can't do authentication of </div><div class="gmail_default" style="font-size:small">course.</div></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">Phill</div><div class="gmail_default" style="font-size:small"><br></div></div></div></div>