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;
Subject: Re: [PATCH] crypto: morus - remove generic and x86 implementations
To:     Ard Biesheuvel <ard.biesheuvel@linaro.org>,
        Samuel Neves <samuel.c.p.neves@gmail.com>
Cc:     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>
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>
 <CAKv+Gu_W9sMrSyqBQv0pZZwgJzCgpSv7CAR6mdH-sJTdMExbHA@mail.gmail.com>
From:   Milan Broz <gmazyland@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <2101a0ba-bf10-45f1-95ba-ed53907c02dc@gmail.com>
Date:   Thu, 27 Jun 2019 09:58:32 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.2
MIME-Version: 1.0
In-Reply-To: <CAKv+Gu_W9sMrSyqBQv0pZZwgJzCgpSv7CAR6mdH-sJTdMExbHA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On 27/06/2019 09:42, Ard Biesheuvel wrote:
> 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.

ok, for me (to keep only recommended variants and completely remove the rest).

There should be no in-kernel users, and we have to deal with algorithms removal
in userspace anyway.

Milan