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: <1565245094-8584-1-git-send-email-pvanleeuwen@verimatrix.com>
 <CAKv+Gu_r+iF=gWk_sMesKSyxSZB5Z5pC6jNQmi8uf+0cY7K-6g@mail.gmail.com>
 <CH2PR20MB296824F38C44E32D8C82D0B8CAD70@CH2PR20MB2968.namprd20.prod.outlook.com>
 <CAKv+Gu_uzt-cQF9ZPuM=4zot7UTogifWk3Pjr7Rcz1QWnqKaog@mail.gmail.com>
 <MN2PR20MB297393DA81B7FFE9C1B904DBCAD70@MN2PR20MB2973.namprd20.prod.outlook.com>
 <CAKv+Gu-vT2tf-UEyxMSE2kRsWEYy+ab6T+37pF23jy_0+M-z2Q@mail.gmail.com> <1353558c-ea2f-b94b-a570-4ca8f3a653ee@gmail.com>
In-Reply-To: <1353558c-ea2f-b94b-a570-4ca8f3a653ee@gmail.com>
From:   Ard Biesheuvel <ard.biesheuvel@linaro.org>
Date:   Sat, 10 Aug 2019 09:05:30 +0300
Message-ID: <CAKv+Gu_EEZqYkXE9tj6n-KE3y4T_rAAS9-BGsdfWEg_sGCKHOQ@mail.gmail.com>
Subject: Re: [PATCHv2] crypto: xts - Add support for Cipher Text Stealing
To:     Milan Broz <gmazyland@gmail.com>
Cc:     Pascal Van Leeuwen <pvanleeuwen@verimatrix.com>,
        Pascal van Leeuwen <pascalvanl@gmail.com>,
        "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" 
        <linux-crypto@vger.kernel.org>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        "David S. Miller" <davem@davemloft.net>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-crypto-owner@vger.kernel.org
Precedence: bulk

On Thu, 8 Aug 2019 at 16:11, Milan Broz <gmazyland@gmail.com> wrote:
>
> On 08/08/2019 12:37, Ard Biesheuvel wrote:
> >>> True. Which is another historical mistake imo, since XTS is only
> >>> specified for AES, but I digress ... :-)
> >>>
> >> Yes, I was also surprised by the use of XTS with other blockciphers.
> >> It sort of violates the don't roll your own crypto paradigm ...
> >> (although some might argue that XTS is supposed to be secure if the
> >> underlying blockcipher is, regardless of what that cipher actually is)
> >>
> >
> > That doesn't really matter. What matters is that nobody took a careful
> > look whether XTS combined with other ciphers is a good idea before
> > throwing it out into the world.
>
> Couldn't resist, but tell that to TrueCrypt authors (if you know them :)
>
> They used XTS for other AES candidates (Serpent, Twofish, also in
> chained modes together).
>
> Older versions used LRW mode, doing the same.
> Even implementing LRW over Blowfish that has 8-byte block size, so you
> need GF(2^64) operations - that is luckily not implemented in Linux kernel
> crypto API :-)
>
> VeraCrypt continued the tradition, adding the Camellia and
> Kuznyetchik (actually discussed GOST standard) to the XTS mix.
>
> But without sarcasm, I do want to support this for users,
> we can map (but not create) such images in cryptsetup, and it is partially
> reason I want dm-crypt to be fully configurable...
>

The cat is already out of the bag, so we're stuck with it in any case.
But going forward, I'd like to apply a bit more sanity to which
combinations of modes we support, which is why I was skeptical about
eboiv potentially being used by authenc(hmac(crc32),lrw(blowfish))
while it is only intended for use with cbc(aes).