Re: [PATCH 2/4] crypto: af_alg - Allow arbitrarily long algorithm names

Hi! On 06/04/17 10:16, Herbert Xu wrote: > This patch removes the hard-coded 64-byte limit on the length > of the algorithm name through bind(2). The address length can > now exceed that. The user-space structure remains unchanged. > In order to use a longer name simply extend the salg_name

Re: dm-crypt IV generation (summary)

On Thu, Apr 06 2017 at 5:29am -0400, Herbert Xu wrote: > On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote: > > Hi all, > > > > I was tasked to post a summary the whole dm-crypt IV generation > > problem and all the suggested solutions along with

Re: [PATCH 1/4] crypto: user - Prepare for CRYPTO_MAX_ALG_NAME expansion

On 06/04/17 10:16, Herbert Xu wrote: > This patch hard-codes CRYPTO_MAX_NAME in the user-space API to > 64, which is the current value of CRYPTO_MAX_ALG_NAME. This patch > also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME > in the user-space API with CRYPTO_MAX_NAME. > > This way the

Re: [PATCH 4/4] crypto: api - Extend algorithm name limit to 128 bytes

On 06/04/17 10:16, Herbert Xu wrote: > With the new explicit IV generators, we may now exceed the 64-byte > length limit on the algorithm name, e.g., with > > echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic))) > > This patch extends the length limit to 128 bytes. > >

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

Hi! On 06/04/17 10:15, Herbert Xu wrote: > On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote: >> This is a regression caused by 856e3f4092 >> ("crypto: seqiv - Add support for new AEAD interface") >> >> As I've said above, I can offer one of the two solutions, which patch should

Re: [PATCH 3/4] xfrm: Prepare for CRYPTO_MAX_ALG_NAME expansion

On 06/04/17 10:16, Herbert Xu wrote: > This patch fixes the xfrm_user code to use the actual array size > rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is > because the array size is fixed at 64 bytes while we want to increase > the in-kernel CRYPTO_MAX_ALG_NAME value. > >

Re: [PATCH 3/4] xfrm: Prepare for CRYPTO_MAX_ALG_NAME expansion

On Thu, Apr 06, 2017 at 04:16:10PM +0800, Herbert Xu wrote: > This patch fixes the xfrm_user code to use the actual array size > rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is > because the array size is fixed at 64 bytes while we want to increase > the in-kernel

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

From: Herbert Xu Date: Thu, 6 Apr 2017 16:15:09 +0800 > As the final patch depends on all three it would be easiest if > we pushed the xfrm patch through the crypto tree. Steffen/David? No objections from me for this going through the crypto tree.

Re: [PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

On Thu, Apr 06, 2017 at 01:58:32PM -0700, David Miller wrote: > From: Herbert Xu > Date: Thu, 6 Apr 2017 16:15:09 +0800 > > > As the final patch depends on all three it would be easiest if > > we pushed the xfrm patch through the crypto tree. Steffen/David? > > No

[PATCH 4/4] crypto: api - Extend algorithm name limit to 128 bytes

With the new explicit IV generators, we may now exceed the 64-byte length limit on the algorithm name, e.g., with echainiv(authencesn(hmac(sha256-generic),cbc(des3_ede-generic))) This patch extends the length limit to 128 bytes. Reported-by: Alexander Sverdlin

[PATCH 0/4] crypto: CRYPTO_MAX_ALG_NAME is too low

On Thu, Mar 16, 2017 at 03:16:29PM +0100, Alexander Sverdlin wrote: > > This is a regression caused by 856e3f4092 > ("crypto: seqiv - Add support for new AEAD interface") > > As I've said above, I can offer one of the two solutions, which patch should > I send? > Or do you see any better

[PATCH 2/4] crypto: af_alg - Allow arbitrarily long algorithm names

This patch removes the hard-coded 64-byte limit on the length of the algorithm name through bind(2). The address length can now exceed that. The user-space structure remains unchanged. In order to use a longer name simply extend the salg_name array beyond its defined 64 bytes length.

[PATCH 3/4] xfrm: Prepare for CRYPTO_MAX_ALG_NAME expansion

This patch fixes the xfrm_user code to use the actual array size rather than the hard-coded CRYPTO_MAX_ALG_NAME length. This is because the array size is fixed at 64 bytes while we want to increase the in-kernel CRYPTO_MAX_ALG_NAME value. Signed-off-by: Herbert Xu

Re: XTS Crypto Not Found In /proc/crypto Even After Compiled for 4.10.1.

On Mon, Mar 13, 2017 at 07:06:01PM +0200, Krzysztof Kozlowski wrote: > > I bisected this to commit f1c131b45410 ("crypto: xts - Convert to > skcipher"). The s5p-sss driver stays the same... but the xts changes and > as a result we have a NULL pointer dereference (actually of value > 0004): > [

[PATCH] padata: free correct variable

The author meant to free the variable that was just allocated, instead of the one that failed to be allocated, but made a simple typo. This patch rectifies that. Signed-off-by: Jason A. Donenfeld Cc: sta...@vger.kernel.org --- kernel/padata.c | 2 +- 1 file changed, 1

Re: [PATCH 2/4] crypto: af_alg - Allow arbitrarily long algorithm names

On Thu, Apr 06, 2017 at 02:32:27PM +0200, Alexander Sverdlin wrote: > > > diff --git a/crypto/af_alg.c b/crypto/af_alg.c > > index 690deca..3556d8e 100644 > > --- a/crypto/af_alg.c > > +++ b/crypto/af_alg.c > > @@ -160,11 +160,11 @@ static int alg_bind(struct socket *sock, struct > > sockaddr

Re: dm-crypt IV generation (summary)

On Fri, Mar 10, 2017 at 02:44:26PM +0100, Ondrej Mosnacek wrote: > Hi all, > > I was tasked to post a summary the whole dm-crypt IV generation > problem and all the suggested solutions along with their drawbacks, so > here it goes... Thanks for the summary. It looks good to me. Something else

[PATCH 1/4] crypto: user - Prepare for CRYPTO_MAX_ALG_NAME expansion

This patch hard-codes CRYPTO_MAX_NAME in the user-space API to 64, which is the current value of CRYPTO_MAX_ALG_NAME. This patch also replaces all remaining occurences of CRYPTO_MAX_ALG_NAME in the user-space API with CRYPTO_MAX_NAME. This way the user-space API will not be modified when we