Re: QUIC-LB update: Eliminate block ciphers?

[Phillip Hallam-Baker <[e-mail]>]

I think this is a different cryptographic construct and we should create a
name for the generic. Something like Keyed Permutation.

Rather than bikeshed the name here, I propose taking it to either CFRG or
the Cryptography list (or both) to socialize the concept. It is quite
possible that there is a prior nomenclature we should follow.


It is not clear to me what the precise security properties required here
are. For my particular application, they are fairly weak because I am only
providing some traffic analysis resistance. I am not interested in
plaintext recovery attack, but I do care about the attacker being able to
discover that E(n), E(N+1) are a sequence.

None of my systems are going to collapse if this primitive is broken but it
might afford a foothold.


On Wed, Oct 6, 2021 at 6:13 PM Martin Thomson <[e-mail]> wrote:

> On Thu, Oct 7, 2021, at 07:02, Christian Huitema wrote:
> > Phil,
> >
> > What we have in the current LB spec is called a "stream cipher", but
> > that's a misnomer. What we have in the spec is actually a variable size
> > block cipher, derived from AES-ECB using a construct similar to FFX.
> > Your review of that algorithm would be appreciated.
>
> Christian,
>
> I would call this a Feistel network, but avoid talking about FFX.  FFX has
> a bunch of guidance about the number of iterations of the network that this
> ignores; to call this FFX or even imply that it is FFX isn't really fair.
> When you get right down to it, the real contribution in FFX is the analysis
> that produces guidance on the number of iterations and the inclusion of
> tweaks; if you use neither, then it's not really FFX.  As additional
> iterations are necessary to maintain a security level, we need to be
> careful about the claims we make in relation to security.
>
>