On 01/08/2016 01:48 PM, Herbert Xu wrote:

On Mon, Jan 04, 2016 at 01:33:54PM +0100, Milan Broz wrote:

quoted

- hmac() is now failing the same way (SETKEY after accept())
(I initially tested without two patches above, these are not in linux-next yet.)
This breaks all cryptsetup TrueCrypt support (and moreover all systems if
kernel crypto API is set as a default vcrypto backend - but that's not default).

Yes algif_hash would need the same compatibility patch and I'm
working on that.

Ok, I fixed this already.

quoted

- cipher_null before worked without setkey, now it requires to set key
(either before or after accept().
This was actually probably bad workaround in cryptsetup, anyway it will now cause
old cryptsetup-reencrypt tool failing with your patches.
(Try "cryptsetup benchmark -c cipher_null-ecb". I am not sure what to do here,
but not requiring setkey for "cipher" that has no key internally seems ok for me...)

Is cipher_null actually used in production or is this just a
benchmark? Using the kernel crypto API to perform no encryption
sounds crazy.

Except benchmarks (I do not care about this) we use cipher_null in cryptsetup-reencrypt
when adding encryption in-place (plaintext-only device is converted
to LUKS, cipher_null is used during conversion for original plainext device,
then offline converted to some real cipher with key).
(It reuses the same logic as re-encryption, IOW volume key change.)

So it is used in production but just for this specific case.

Thanks,
Milan