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>
In-Reply-To: <e9d045c6-f6e2-a0d2-b1f2-bebee5d027f4@gmail.com>
From:   Samuel Neves <samuel.c.p.neves@gmail.com>
Date:   Wed, 26 Jun 2019 22:11:03 +0100
Message-ID: <CAEX_ruEDA9ZG+6aA_jTBSq-MM=pOrdxoJA2x0LPF3dkYk76kCQ@mail.gmail.com>
Subject: Re: [PATCH] crypto: morus - remove generic and x86 implementations
To:     Milan Broz <gmazyland@gmail.com>
Cc:     Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        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, 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.

[1] https://eprint.iacr.org/2018/292