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@xxxxxxxxxx> wrote: > > On Fri, 7 May 2021 at 08:12, Kestrel seventyfour > <kestrelseventyfour@xxxxxxxxx> 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.
