On Wed, May 15, 2019 at 08:49:48PM +0200, Christophe Leroy wrote:
Le 15/05/2019 Ã 16:05, Horia Geanta a ÃcritÂ:
On 5/15/2019 3:29 PM, Christophe Leroy wrote:
Selftests report the following:Reviewed-by: Horia GeantÄ <horia.geanta@xxxxxxx>
[ 2.984845] alg: skcipher: cbc-aes-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
[ 2.995377] 00000000: 3d af ba 42 9d 9e b4 30 b4 22 da 80 2c 9f ac 41
[ 3.032673] alg: skcipher: cbc-des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
[ 3.043185] 00000000: fe dc ba 98 76 54 32 10
[ 3.063238] alg: skcipher: cbc-3des-talitos encryption test failed (wrong output IV) on test vector 0, cfg="in-place"
[ 3.073818] 00000000: 7d 33 88 93 0f 93 b2 42
This above dumps show that the actual output IV is indeed the input IV.
This is due to the IV not being copied back into the request.
This patch fixes that.
Signed-off-by: Christophe Leroy <christophe.leroy@xxxxxx>
It's missing a Fixes: tag and a Cc: to stable.
I'll resend tomorrow.
While here, could you please check ecb mode (which by definition does not have
an IV) is behaving correctly?
Looking in driver_algs[] list of crypto algorithms supported by talitos,
ecb(aes,des,3des) are declared with ivsize != 0.
According to /proc/crypto, test are passed for ecb.
Did you try enabling CONFIG_CRYPTO_MANAGER_EXTRA_TESTS? There is now a check
that the driver's ivsize matches the generic implementation's:
if (ivsize != crypto_skcipher_ivsize(generic_tfm)) {
pr_err("alg: skcipher: ivsize for %s (%u) doesn't match generic impl (%u)\n",
driver, ivsize, crypto_skcipher_ivsize(generic_tfm));
err = -EINVAL;
goto out;
}
For ECB that means the ivsize must be 0.
AFAICS the talitos driver even accesses the IV for ECB, which is wrong; and the
only reason this isn't crashing the self-tests already is that they are confused
by the declared ivsize being nonzero so they don't pass NULL as they should.