[Cryptography] Shortening block cipher length...

[Phillip Hallam-Baker]

On Mon, Mar 29, 2021 at 10:21 PM Peter Gutmann <pgut001 at cs.auckland.ac.nz>
wrote:

> Jon Callas <jon at callas.org> writes:
>
> >I think it's very different when you're encrypting a 64-bit block,
> >especially a single one, which is what I understand the use case to be.
>
> Oh, Phil mentioned 16-32 bytes so I assumed it was more than one block, at
> least of any common block cipher.  In which case a tweakable block cipher
> might be the appropriate solution, with T-HEAD as the tweak.
>

bits, not bytes.

These are fractions of an AES block. Going larger is fairly easy, can just
use Ciphertext stealing.



> It really needs a bit more info:
>
> - Can you use nonstandard building blocks or do you need to stick with
> e.g.
>   AES?
> - Do you have room to communicate nonces/tweaks?  How much?
> - Are dictionary attacks an issue, or is there enough unique material
> (which
>   Phil's comment about T-HEAD implies) or changing keys that it's not an
>   issue?
>
> If the presence of a nonce and use of nonstandard builing blocks is a
> problem then there's the nonce-less two-pass encryption trick invented by
> Colin Plumb which takes any standard block cipher, without needing a tweak/
> nonce/whatever, and makes it as wide as you need it to be.
>

Let me be more precise.

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.

So this really needs to be a full permutation. There is no space outside
the identifier. No tweaks, no nonces.

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 (!).

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.

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, ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210330/4691c851/attachment.htm>