Re: [PATCH 1/2] crypto: af_alg - Add nokey compatibility path

[Herbert Xu]

On Mon, Jan 04, 2016 at 01:33:54PM +0100, Milan Broz wrote:
>
> - 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.

> - 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.

> As I said, I'll fix it in cryptsetup upstream but we are breaking  a lot of existing systems.
> Isn't there better way, how to fix it?

Setting the key after accept has always been wrong.  It's just
that it hasn't been noticed until now.  The main crypto socket
corresponds to the tfm object and is shared by all the child
sockets produced by accept(2).  So once you have child sockets
which may then be used by another thread you must not modify
the parent socket/tfm in any way, and in particular you must
not change the key.

Cheers,
-- 
Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt