<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 Mon, Mar 29, 2021 at 10:21 PM Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</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">Jon Callas <<a href="mailto:jon@callas.org" target="_blank">jon@callas.org</a>> writes:<br>
<br>
>I think it's very different when you're encrypting a 64-bit block, <br>
>especially a single one, which is what I understand the use case to be.<br>
<br>
Oh, Phil mentioned 16-32 bytes so I assumed it was more than one block, at <br>
least of any common block cipher.  In which case a tweakable block cipher <br>
might be the appropriate solution, with T-HEAD as the tweak.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">bits, not bytes.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">These are fractions of an AES block. Going larger is fairly easy, can just use Ciphertext stealing. </div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
It really needs a bit more info:<br>
<br>
- Can you use nonstandard building blocks or do you need to stick with e.g. <br>
  AES?<br>
- Do you have room to communicate nonces/tweaks?  How much?<br>
- Are dictionary attacks an issue, or is there enough unique material (which<br>
  Phil's comment about T-HEAD implies) or changing keys that it's not an <br>
  issue?<br>
<br>
If the presence of a nonce and use of nonstandard builing blocks is a <br>
problem then there's the nonce-less two-pass encryption trick invented by <br>
Colin Plumb which takes any standard block cipher, without needing a tweak/<br>
nonce/whatever, and makes it as wide as you need it to be.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">Let me be more precise.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">This is not a one shot affair. The idea is that there will be a large number of streams created and in the typical case, we certainly expect that if we allow 32 bits for the stream ID, we are expecting to generate up to 2^32 identifiers.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">So this really needs to be a full permutation. There is no space outside the identifier. No tweaks, no nonces.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">One approach is to simply use AES and accept that the stream identifiers will occupy 128 bits. Which is quite an overhead - 1% of the total packet data (!).</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"></div><div class="gmail_default" style="font-size:small">One of the applications here is that a service might be fielding requests from a million or so devices. We don't want to leak information about the state of the service because this might help a DoS attacker work out how heavily loaded the service is. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If the attacker submitts 1000 requests and they are given stream ids 3224, 3225, 3226m the attacker knows this host is likely less loaded than one that returns 3224, 3534, 3834, ...</div><br></div><div><br></div><div><br></div><div> </div></div></div>