[PATCH RFC 2/7] crypto/compress: introduce sychronuous compression API

This introduces new compression APIs. Major change is that APIs are stateless. Instead of previous implementation, tfm objects doesn't embedded any context so we can de/compress concurrently with one tfm object. Instead, thsi de/compression context is coupled with the request. This architecture

[PATCH RFC 1/7] crypto/compress: remove unused pcomp interface

It is unused now, so remove it. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 19 -- crypto/Makefile| 2 - crypto/pcompress.c | 115 --- crypto/testmgr.c | 223 --

[PATCH 2/2] crypto: algif_skcipher - Add nokey compatibility path

This patch adds a compatibility path to support old applications that do acept(2) before setkey. Signed-off-by: Herbert Xu diff --git a/crypto/algif_skcipher.c b/crypto/algif_skcipher.c index f4431bc..110bab4 100644 --- a/crypto/algif_skcipher.c +++

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

On Sun, Jan 03, 2016 at 10:42:28AM +0100, Milan Broz wrote: > > yes, basically it prepares socket()/bind()/accept() and then it calls setkey > once. > (I'll try to fix in next releases to call setkey first though.) OK please try these two patches (warning, totally untested). ---8<--- This

[PATCH RFC 4/7] crypto/lzo: support SCOMPRESS alg type

For proof of concept, SCOMPRESS alg type is implemented for lzo. Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/lzo.c | 94 ++ 2 files changed, 82 insertions(+), 13 deletions(-) diff --git

[PATCH RFC 0/7] Introduce new async/sync compression APIs

Happy New Year! This patchset is to introduce new compression APIs. It supports async/sync compression although there is no async compression driver yet. But, async APIs can be used as front-end to sync compression algorithm. Major change is that now APIs are stateless. Instead of previous

[PATCH RFC 7/7] crypto/lzo: add CRYPTO_ALG_SCOMPRESS_DECOMP_NOCTX cra_flags

Signed-off-by: Joonsoo Kim --- crypto/lzo.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/crypto/lzo.c b/crypto/lzo.c index 47998e9..90afbf9 100644 --- a/crypto/lzo.c +++ b/crypto/lzo.c @@ -142,7 +142,8 @@ static struct scomp_alg scomp = {

[PATCH RFC 6/7] crypto/compress: add algorithm type specific flag, DECOMP_NOCTX

Signed-off-by: Joonsoo Kim --- crypto/testmgr.c | 2 ++ include/crypto/compress.h | 8 include/linux/crypto.h| 6 ++ 3 files changed, 16 insertions(+) diff --git a/crypto/testmgr.c b/crypto/testmgr.c index bd0c639..acd7428 100644 ---

[PATCH RFC 5/7] crypto: testmgr: add scompress/acompress test

Signed-off-by: Joonsoo Kim --- crypto/Kconfig | 1 + crypto/testmgr.c | 173 --- 2 files changed, 165 insertions(+), 9 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index b4b485c..f487502 100644 ---

[PATCH RFC 3/7] crypto: add asynchronous compression support

From: Weigang Li Now, asynchronous compression APIs are supported. There is no asynchronous compression driver now but this APIs can be used as front-end to synchronous compression algorithm. In this case, scatterlist would be linearlized so it would cause some overhead.

Re: [PATCH v2] crypto: algif_skcipher - Require setkey before accept(2)

On 01/03/2016 02:31 AM, Herbert Xu wrote: > On Sat, Jan 02, 2016 at 09:18:30PM +0100, Milan Broz wrote: >> >> But I cannot change thousands of cryptsetup installations that are actively >> using that code. >> This is clear userspace breakage which should not happen this way. > > I'll try to add

Re: next-20151231 - aes crypto algorithm went missing?

On 01/03/2016 06:34 AM, Valdis Kletnieks wrote: > So booting into a next-20151222 kernel, I can mount an external drive > that uses cryptLuks. I try -1231, and I get this failure: > > Failed to setup dm-crypt key mapping for device /dev/sdb2. > Check that kernel supports aes-cbc-essiv:sha256

next-20151231 - aes crypto algorithm went missing?

So booting into a next-20151222 kernel, I can mount an external drive that uses cryptLuks. I try -1231, and I get this failure: Failed to setup dm-crypt key mapping for device /dev/sdb2. Check that kernel supports aes-cbc-essiv:sha256 cipher (check syslog for more info). Tracked it down to