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>,
        Eric Biggers <ebiggers@kernel.org>
Cc:     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>
From:   Milan Broz <gmazyland@gmail.com>
Openpgp: preference=signencrypt
Message-ID: <ca908099-3305-9764-dbf2-adc7a256ad59@gmail.com>
Date:   Wed, 26 Jun 2019 09:00:10 +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+Gu8P4AUNbf636d=h=RDFV+CPEZCoPi9EZ+OtKEd5cBky5g@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 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.


Long story (beware, a rant below:)

We were very strict in backward support of almost everything in cryptsetup/dm-crypt
(including unreleased versions) for the last 10 years.

But I think we need to change the approach in some specific cases.

For the last years (this topic was a part of my Ph.D. study) I was trying to help
to investigate new practical approaches to the sector level encryption, and apparently,
not everything is a success.

I truly believe that we have to start to use authenticated encryption in future (in general).

Unfortunately, once we are trying to talk to academic people, I found quite strict
resistance (or even ignorance) regarding practical applications.
Maybe it is just my perception, but once papers are published, nobody cares what
happens next.

In the time we need to experiment with new AEAD algorithms, the CAESAR crypto
competition was in an almost-final state for months.
Maybe post-quantum was more important at the time, maybe the practitioners
and researchers time scale differs here in order of magnitude...

So we have decided to take a risk to implement some AEAD ciphers (where the theoretic
background looked good - at that time) and use them and investigate all the "engineering"
problems around it.
Everything was designed to be algorithm-agnostic, precisely to be able to switch it later.

Yes, we can be conservative and wait for years. The risk is that if nobody uses it,
nobody analyzes it. And even then the best algorithms are being broken later, we need
just to deal with it.

So my point is:

Let's try to use state-of-the-art things, but let's be prepared to also retract
it quickly if it becomes apparent that this is not secure or the goal was not met.

We will break some systems from time to time, but it is still better than keeping
an army of known flawed algorithms in the kernel.
With help from academic research people, it can happen very rarely though.

There is always a conservative selection of crypto (with all the certifications
theatre around), I am *not* talking about this - IMO here the compatibility is a must.

Milan

p.s.
We planned to be able to use the reencryption feature to switch to different
ciphers on existing devices in such cases, but unfortunately, for now, it works
only for length-preserving modes.
Authenticated encryption will be supported later (and not in all cases).
It will improve, though.