Re: xts fuzz testing and lack of ciphertext stealing support

[Eric Biggers <ebiggers@kernel.org>]

Hi Horia,

On Tue, Jul 16, 2019 at 05:46:29PM +0000, Horia Geanta wrote:
> Hi,
> 
> With fuzz testing enabled, I am seeing xts(aes) failures on caam drivers.
> 
> Below are several failures, extracted from different runs:
> 
> [    3.921654] alg: skcipher: xts-aes-caam encryption unexpectedly succeeded on test vector "random: len=40 klen=64"; expected_error=-22, cfg="random: inplace use_finup nosimd src_divs=[57.93%@+11, 37.18%@+164, <reimport>0.68%@+4, 0.50%@+305, 3.71%@alignmask+3975]" 
> 
> [    3.726698] alg: skcipher: xts-aes-caam encryption unexpectedly succeeded on test vector "random: len=369 klen=64"; expected_error=-22, cfg="random: inplace may_sleep use_digest src_divs=[100.0%@alignmask+584]" 
> 
> [    3.741082] alg: skcipher: xts-aes-caam encryption unexpectedly succeeded on test vector "random: len=2801 klen=64"; expected_error=-22, cfg="random: inplace may_sleep use_digest src_divs=[100.0%@+6] iv_offset=18"
> 
> It looks like the problem is not in CAAM driver.
> More exactly, fuzz testing is generating random test vectors and running
> them through both SW generic (crypto/xts.c) and CAAM implementation:
> -SW generic implementation of xts(aes) does not support ciphertext stealing
> and throws -EINVAL when input is not a multiple of AES block size (16B)
> -caam has support for ciphertext stealing, and allows for any input size
> which results in "unexpectedly succeeded" error messages.
> 
> Any suggestion how this should be fixed?
> 
> Thanks,
> Horia

I don't think drivers should allow inputs the generic implementation doesn't,
since those inputs aren't tested by the crypto self-tests (so how do you know
it's even correct?), and people could accidentally rely on the driver-specific
behavior and then be unable to migrate to another platform or implementation.

So for now I recommend just updating the caam driver to return -EINVAL on XTS
inputs not evenly divisible by the block size.

Of course, if there are actual use cases for XTS with ciphertext stealing in the
kernel, we could add it to all the other implementations too.  But I'm not aware
of any currently.  Don't all XTS users in the kernel pass whole blocks?

- Eric