Received-SPF: pass (google.com: best guess record for domain of linux-crypto-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <20190625145254.28510-1-ard.biesheuvel@linaro.org>
 <20190625171234.GB81914@gmail.com> <CAKv+Gu8P4AUNbf636d=h=RDFV+CPEZCoPi9EZ+OtKEd5cBky5g@mail.gmail.com>
 <ca908099-3305-9764-dbf2-adc7a256ad59@gmail.com> <CAKv+Gu9jAqGAYg8f_rBVbve=L3AQb_xKnpmnsqrZ3m7VLnaz1g@mail.gmail.com>
 <e9d045c6-f6e2-a0d2-b1f2-bebee5d027f4@gmail.com> <CAEX_ruEDA9ZG+6aA_jTBSq-MM=pOrdxoJA2x0LPF3dkYk76kCQ@mail.gmail.com>
In-Reply-To: <CAEX_ruEDA9ZG+6aA_jTBSq-MM=pOrdxoJA2x0LPF3dkYk76kCQ@mail.gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Thu, 27 Jun 2019 09:42:45 +0200
Message-ID: <CAKv+Gu_W9sMrSyqBQv0pZZwgJzCgpSv7CAR6mdH-sJTdMExbHA@mail.gmail.com>
Subject: Re: [PATCH] crypto: morus - remove generic and x86 implementations
To:     Samuel Neves <samuel.c.p.neves@gmail.com>
Cc:     Milan Broz <gmazyland@gmail.com>,
        Eric Biggers <ebiggers@kernel.org>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Ondrej Mosnacek <omosnace@redhat.com>,
        Geert Uytterhoeven <geert@linux-m68k.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, 26 Jun 2019 at 23:11, Samuel Neves <samuel.c.p.neves@gmail.com> wrote:
>
> , On Wed, Jun 26, 2019 at 8:40 AM Milan Broz <gmazyland@gmail.com> wrote:
> >
> > On 26/06/2019 09:15, Ard Biesheuvel wrote:
> >
> > > Thanks for the insight. So I guess we have consensus that MORUS should
> > > be removed. How about aegis128l and aegis256, which have been
> > > disregarded in favor of aegis128 by CAESAR (note that I sent an
> > > accelerated ARM/arm64 version of aegis128 based on the ARMv8 crypto
> > > instructions, in case you missed it)
> >
> > Well, there are similar cases, see that Serpent supports many keysizes, even 0-length key (!),
> > despite the AES finalists were proposed only for 128/192/256 bit keys.
> > (It happened to us several times during tests that apparent mistype in Serpent key length
> > was accepted by the kernel...)
>
> I'm not sure the Serpent case is comparable. In Serpent, the key can
> be any size below 256 bits, but internally the key is simply padded to
> 256 bits and the algorithm is fundamentally the same. There are no
> speed differences between different keys sizes.
>
> On the other hand, AEGIS128, AEGIS256, and AEGIS128L are different
> algorithms, with different state sizes and state update functions. The
> existing cryptanalysis of AEGIS consists solely of [1] (which is the
> paper that directly inspired the MORUS cryptanalysis), which does not
> look at AEGIS128L at all. In effect, to my knowledge there are no
> known cryptanalytic results on AEGIS128L, which I imagine to be one of
> the main reasons why it did not end up in the CAESAR portfolio. But
> AEGIS128L is by far the fastest option, and a user is probably going
> to be naturally tempted to use it instead of the other variants.
>

Indeed. So that would actually argue for removing the optimized x86
implementation, but tbh, I'd rather remove aegis128l and aegis256
entirely, given that no recommendations exist for its use in any
particular context, and given the CAESAR outcome, that is unlikely to
change in the future.