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>
In-Reply-To: <ca908099-3305-9764-dbf2-adc7a256ad59@gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Wed, 26 Jun 2019 09:15:38 +0200
Message-ID: <CAKv+Gu9jAqGAYg8f_rBVbve=L3AQb_xKnpmnsqrZ3m7VLnaz1g@mail.gmail.com>
Subject: Re: [PATCH] crypto: morus - remove generic and x86 implementations
To:     Milan Broz <gmazyland@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>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Wed, 26 Jun 2019 at 09:00, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 25/06/2019 20:37, Ard Biesheuvel wrote:
> > On Tue, 25 Jun 2019 at 19:12, Eric Biggers <ebiggers@kernel.org> wrote:
> >>
> >> [+Cc Milan]
>
> I was discussing this with Ondra before he sent the reply, anyway comments below:
>
> >> On Tue, Jun 25, 2019 at 04:52:54PM +0200, Ard Biesheuvel wrote:
> >>> MORUS was not selected as a winner in the CAESAR competition, which
> >>> is not surprising since it is considered to be cryptographically
> >>> broken. (Note that this is not an implementation defect, but a flaw
> >>> in the underlying algorithm). Since it is unlikely to be in use
> >>> currently, let's remove it before we're stuck with it.
> >>>
> >>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>
> ...
> >>
> >> Maybe include a link to the cryptanalysis paper
> >> https://eprint.iacr.org/2019/172.pdf in the commit message, so people seeing
> >> this commit can better understand the reasoning?
> >>
> >
> > Sure.
>
> Yes, definitely include the link please.
>
> >> Otherwise this patch itself looks fine to me, though I'm a little concerned
> >> we'll break someone actually using MORUS.  An alternate approach would be to
> >> leave just the C implementation, and make it print a deprecation warning for a
> >> year or two before actually removing it.  But I'm not sure that's needed, and it
> >> might be counterproductive as it would allow more people to start using it.
> >>
> >
> > Indeed. 'Breaking userspace' is permitted if nobody actually notices,
> > and given how broken MORUS is, anyone who truly cares about security
> > wouldn't have chosen it to begin with. And if it does turn out to be a
> > real issue, we can always put the C version back where it was.
>
> >
> >> From a Google search I don't see any documentation floating around specifically
> >> telling people to use MORUS with cryptsetup, other than an email on the dm-crypt
> >> mailing list (https://www.spinics.net/lists/dm-crypt/msg07763.html) which
> >> mentioned it alongside other options.  So hopefully there are at most a couple
> >> odd adventurous users, who won't mind migrating their data to a new LUKS volume.
>
> Yes, there are perhaps some users.
>
> TL;DR: Despite it, I am for completely removing the MORUS cipher now form the kernel.
> Cryptsetup integrity extension (authenticated encryption) is still marked experimental.
>

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)