Received-SPF: pass (google.com: domain of linux-crypto-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
MIME-Version: 1.0
References: <CAE9cyGTQZXW-6YsmHu3mGSHonTztBszqaYske7PKgz0pWHxQKA@mail.gmail.com>
 <CAMj1kXHOVRDAt7-C8UKi=5=MAgQ9kQz=HUtiuK_gt7ch_i950w@mail.gmail.com>
In-Reply-To: <CAMj1kXHOVRDAt7-C8UKi=5=MAgQ9kQz=HUtiuK_gt7ch_i950w@mail.gmail.com>
From:   Mike Brooks <m@ib.tc>
Date:   Tue, 11 May 2021 11:01:11 -0700
Message-ID: <CALFqKjQVz7xyEZN0XWdGGHOfP4wRMsnU6amN11ege0XXbhQq8Q@mail.gmail.com>
Subject: Re: or should block size for xts.c set to 1 instead of AES block size?
To:     Ard Biesheuvel <ardb@kernel.org>
Cc:     Kestrel seventyfour <kestrelseventyfour@gmail.com>,
        Herbert Xu <herbert@gondor.apana.org.au>,
        Eric Biggers <ebiggers@kernel.org>,
        Linux Crypto Mailing List <linux-crypto@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

xst(ecb()) can only produce a minimum of AES_BLOCK_SIZE of data -
sending in a smaller dataset will still return AES_BLOCK_SIZE of data.
If you try and pass in lets say 4 bytes - and then you truncate the
response to 4 bytes you'll lose data.

Moving to a smaller size is asking for trouble. IMHO.

-Michael Brooks

On Tue, May 11, 2021 at 8:48 AM Ard Biesheuvel <ardb@kernel.org> wrote:
>
> On Fri, 7 May 2021 at 08:12, Kestrel seventyfour
> <kestrelseventyfour@gmail.com> wrote:
> >
> > Hi,
> >
> > one more thought, shouldn't the block size for generic xts set to 1 in
> > order to reflect that any input size length is allowed to the
> > algorithm?
> >
>
> I think this was discussed at some point on the list, and Herbert
> seemed to suggest that 1 was a better choice than AES_BLOCK_SIZE.
> You'd have to set the chunksize, though, to ensure that the input is
> presented in the right granularity, i.e., to ensure that the skcipher
> walk layer never presents less than chunksize bytes unless it is the
> end of the input.
>
> However, this is a flag day change, so you'd need to update all
> implementations at the same time. Otherwise, the extended tests (which
> compare accelerated implementations with xts(ecb(aes-generic))) will
> start failing on the cra_blocksize mismatch.