On Fri, Jun 03, 2016 at 02:48:34PM +0800, Baolin Wang wrote:
>
> If we move the IV generation into the crypto API, we also can not
> handle every algorithm with the bulk interface. Cause we also need to
> use different methods to map one whole bio or map one sector according
> to the algorithm whet
Hi Herbet,
On 2 June 2016 at 16:26, Herbert Xu wrote:
> On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote:
>> Now some cipher hardware engines prefer to handle bulk block rather than one
>> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
>> the intermediate
Am Donnerstag, 2. Juni 2016, 18:01:04 schrieb Marcus Meissner:
Hi Marcus, Herbert
> Hi,
>
> In February I already tagged some authenc ciphers for FIPS compatibility.
>
> I currently revisit this to get testmgr running all the tests in strict FIPS
> mode.
>
> The authenc() class is troublesome.
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Thursday, June 2, 2016 5:33 PM
To: Dey, Megha
Cc: tim.c.c...@linux.intel.com; da...@davemloft.net;
linux-crypto@vger.kernel.org; linux-ker...@vger.kernel.org; Yu, Fenghua
Subject: Re: [PATCH 2/2] crypto :
From: Megha Dey
Currently there are several checkpatch warnings in the sha1_mb.c file:
'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
syntax of some multi-line comments are not correct. This patch fixes
these issues.
Signed-off-by: Megha Dey
Signed-off-by: Herbert Xu
---
From: Megha Dey
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm. This patch introduces
a async interface for even the inner algo
From: Megha Dey
Currently, sha1-mb uses an async interface for the outer algorithm
and a sync interface for the inner algorithm.
Herbert wants the sha1-mb algorithm to have an async implementation:
https://lkml.org/lkml/2016/4/5/286.
This patch introduces a async interface for even the inner algo
On Thu, Jun 02, 2016 at 10:20:20AM -0700, Megha Dey wrote:
>
> > > @@ -439,17 +444,18 @@ static int mcryptd_hash_finup_enqueue(struct
> > > ahash_request *req)
> > > static void mcryptd_hash_digest(struct crypto_async_request *req_async,
> > > int err)
> > > {
> > > struct mcryptd_hash_ctx *c
On Thu, 2016-06-02 at 18:33 +0800, Herbert Xu wrote:
> On Tue, May 31, 2016 at 02:42:21PM -0700, Megha Dey wrote:
> >
> > @@ -416,8 +421,8 @@ static void mcryptd_hash_finup(struct
> > crypto_async_request *req_async, int err)
> >
> > if (unlikely(err == -EINPROGRESS))
> > goto ou
Hi,
In February I already tagged some authenc ciphers for FIPS compatibility.
I currently revisit this to get testmgr running all the tests in strict FIPS
mode.
The authenc() class is troublesome.
There is a HASH + ENC part of this method, but you can also add associated data,
which is not enc
Am Donnerstag, 2. Juni 2016, 16:55:26 schrieb Herbert Xu:
Hi Herbert,
>
> Why don't you put the result in a temporary buffer and then copy
> it? These things are tiny, right?
The KDFs are usually used for output sizes between one and 4 keys. So,
commonly it is expected that not more than 200 o
The current crypto engine allow only ablkcipher_request to be enqueued.
Thus denying any use of it for hardware that also handle hash algo.
This patch convert all ablkcipher_request references to the
more general crypto_async_request.
Since the crypto engine is now generalist, this patch rename
c
Hello
I wanted to use the crypto engine for my Allwinner crypto driver but something
prevented me to use it: it cannot enqueue hash requests.
This patch convert crypto engine to permit enqueuing of ahash_requests.
It also convert the only driver using crypto engine.
The modifications against omap
The following patch set introduces acomp, a generic asynchronous
(de)compression api with support for SG lists.
We propose a new crypto type called crypto_acomp_type, a new struct acomp_alg
and struct crypto_acomp, together with number of helper functions to register
acomp type algorithms and alloc
This patch implements an scomp backend for the lz4hc compression algorithm.
This way, lz4hc is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4hc.c | 92 +--
2 files changed, 83 insertions
This patch implements an scomp backend for the deflate compression
algorithm. This way, deflate is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/deflate.c | 111 +-
2 files changed, 102 in
This patch introduces acomp, an asynchronous compression api that uses
scatterlist buffers.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig | 10 ++
crypto/Makefile |2 +
crypto/acompress.c | 118
crypto/crypto_
This patch implements an scomp backend for the lzo compression algorithm.
This way, lzo is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lzo.c | 97 +++-
2 files changed, 83 insertions(+)
This patch implements an scomp backend for the 842 compression algorithm.
This way, 842 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/842.c | 82 +--
crypto/Kconfig |1 +
2 files changed, 80 insertions(+),
This patch implements an scomp backend for the lz4 compression algorithm.
This way, lz4 is exposed through the acomp api.
Signed-off-by: Giovanni Cabiddu
---
crypto/Kconfig |1 +
crypto/lz4.c | 91 +--
2 files changed, 82 insertions(+),
Add a synchronous back-end (scomp) to acomp. This allows to easily expose
the already present compression algorithms in LKCF via acomp
Signed-off-by: Giovanni Cabiddu
---
crypto/Makefile |1 +
crypto/acompress.c | 49 +++-
crypto/scompress.c
Move hash to 0xe to free up the space for acomp/scomp
Signed-off-by: Giovanni Cabiddu
---
include/linux/crypto.h | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/include/linux/crypto.h b/include/linux/crypto.h
index 6e28c89..d844cbc 100644
--- a/include/linux/cry
This patch adds tests to the test manager for algorithms exposed through
the acomp api
Signed-off-by: Giovanni Cabiddu
---
crypto/testmgr.c | 158 +-
1 files changed, 145 insertions(+), 13 deletions(-)
diff --git a/crypto/testmgr.c b/crypto/t
Hi Herbert,
apologies, I missed this email.
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Herbert Xu
> Sent: Tuesday, May 31, 2016 7:42 AM
> To: Benedetto, Salvatore
> Cc: linux-crypto@vger.kernel.org
> Subject
Am Donnerstag, 2. Juni 2016, 17:42:11 schrieb Herbert Xu:
Hi Herbert,
> On Thu, Jun 02, 2016 at 11:31:22AM +0200, Stephan Mueller wrote:
> > The skcipher API, however, wants to encrypt an entire input data stream.
> > That means the skcipher API requires the length of the input data stream
> > to
On Thu, 2016-06-02 at 12:43 +0200, Clemens Ladisch wrote:
> Bob Ham wrote:
> > Adds support for the Araneus Alea I USB hardware Random Number
> > Generator. This RNG creates entropy at a high rate, about 100kb/s.
> >
> > Signed-off-by: Bob Ham
> > ---
> >
> > +++ b/drivers/char/hw_random/alea.c
>
Bob Ham wrote:
> Adds support for the Araneus Alea I USB hardware Random Number
> Generator. This RNG creates entropy at a high rate, about 100kb/s.
>
> Signed-off-by: Bob Ham
> ---
>
> +++ b/drivers/char/hw_random/alea.c
Why didn't you just add the device ID to chaoskey.c?
(Because that one is
On Tue, May 31, 2016 at 02:42:20PM -0700, Megha Dey wrote:
> From: Megha Dey
>
> Currently there are several checkpatch warnings in the sha1_mb.c file:
> 'WARNING: line over 80 characters' in the sha1_mb.c file. Also, the
> syntax of some multi-line comments are not correct. This patch fixes
> th
On Tue, May 31, 2016 at 01:11:57PM +0200, Stephan Mueller wrote:
> The CTR DRBG code always set the key for each sym cipher invocation even
> though the key has not been changed.
>
> The patch ensures that the setkey is only invoked when a new key is
> generated by the DRBG.
>
> With this patch,
On Tue, May 31, 2016 at 02:42:21PM -0700, Megha Dey wrote:
>
> @@ -416,8 +421,8 @@ static void mcryptd_hash_finup(struct
> crypto_async_request *req_async, int err)
>
> if (unlikely(err == -EINPROGRESS))
> goto out;
> -
> - err = shash_ahash_mcryptd_finup(req, &rctx->desc
On Tue, May 31, 2016 at 04:36:21PM +0100, Salvatore Benedetto wrote:
> Add key-agreement protocol primitives (kpp) API which allows to
> implement primitives required by protocols such as DH and ECDH.
> The API is composed mainly by the following functions
> * set_params() - It allows the user to
On Thu, Jun 02, 2016 at 11:38:35AM +0200, LABBE Corentin wrote:
>
> Since my patch is small and easy (and only one client is modified), do you
> mind if I choose the first one ?
Sure.
> I will add this type checking on my patch against omap-aes/des.
Thanks,
--
Email: Herbert Xu
Home Page: htt
On Thu, Jun 02, 2016 at 11:31:22AM +0200, Stephan Mueller wrote:
>
> The skcipher API, however, wants to encrypt an entire input data stream. That
> means the skcipher API requires the length of the input data stream to
> generate an equally sized output data stream. But that is not what we have
On Thu, Jun 02, 2016 at 05:19:40PM +0800, Herbert Xu wrote:
> On Thu, Jun 02, 2016 at 11:12:13AM +0200, LABBE Corentin wrote:
> > On Thu, Jun 02, 2016 at 04:32:59PM +0800, Herbert Xu wrote:
> > > On Mon, May 30, 2016 at 03:32:01PM +0200, LABBE Corentin wrote:
> > > > The current crypto engine allow
Am Donnerstag, 2. Juni 2016, 16:40:12 schrieb Herbert Xu:
Hi Herbert,
> On Tue, May 31, 2016 at 01:23:21PM +0200, Stephan Mueller wrote:
> > Hence my question: shall we leave the HMAC DRBG as default or shall we use
> > the CTR DRBG as default?
>
> I don't really care one way or another.
>
> BT
On Thu, Jun 02, 2016 at 11:12:13AM +0200, LABBE Corentin wrote:
> On Thu, Jun 02, 2016 at 04:32:59PM +0800, Herbert Xu wrote:
> > On Mon, May 30, 2016 at 03:32:01PM +0200, LABBE Corentin wrote:
> > > The current crypto engine allow only ablkcipher_request to be enqueued.
> > > Thus denying any use
On Tue, May 31, 2016 at 02:55:30PM +0100, Giovanni Cabiddu wrote:
> This patch introduces qdecomp, an asynchronous decompression api.
> qdecomp is a front-end for acomp and scomp algorithms which do not
> not need additional vmalloc work space for decompression.
>
> Signed-off-by: Giovanni Cabiddu
On Tue, May 31, 2016 at 02:55:28PM +0100, Giovanni Cabiddu wrote:
>
> +/**
> + * struct acomp_req - asynchronous (de)compression request
> + *
> + * @base: Common attributes for asynchronous crypto requests
> + * @src: Source Data
> + * @dst: Destination data
> + * @slen: Size of
On Thu, Jun 02, 2016 at 04:32:59PM +0800, Herbert Xu wrote:
> On Mon, May 30, 2016 at 03:32:01PM +0200, LABBE Corentin wrote:
> > The current crypto engine allow only ablkcipher_request to be enqueued.
> > Thus denying any use of it for hardware that also handle hash algo.
> >
> > This patch conve
On Tue, May 31, 2016 at 01:50:57PM +0200, Stephan Mueller wrote:
> Hi,
>
> this patch set implements all three key derivation functions defined in
> SP800-108.
>
> The implementation is provided as a template for random number generators,
> since a KDF can be considered a form of deterministic RN
On Tue, May 31, 2016 at 01:52:32PM +0200, Stephan Mueller wrote:
>
> + * NOTE: Technically you can use one buffer for holding the label_context and
> + *the outbuf in the example above. Howerver, multiple rounds of the
> + *KDF are to be expected with the input must always be the same.
> +
On Tue, May 31, 2016 at 01:23:21PM +0200, Stephan Mueller wrote:
>
> Hence my question: shall we leave the HMAC DRBG as default or shall we use
> the
> CTR DRBG as default?
I don't really care one way or another.
BTW why did you use the crypto_cipher aes interface instead of
the crypto_skcipher
On Mon, May 30, 2016 at 03:32:01PM +0200, LABBE Corentin wrote:
> The current crypto engine allow only ablkcipher_request to be enqueued.
> Thus denying any use of it for hardware that also handle hash algo.
>
> This patch convert all ablkcipher_request references to the
> more general crypto_asyn
On Fri, May 27, 2016 at 07:11:23PM +0800, Baolin Wang wrote:
> Now some cipher hardware engines prefer to handle bulk block rather than one
> sector (512 bytes) created by dm-crypt, cause these cipher engines can handle
> the intermediate values (IV) by themselves in one bulk block. This means we
>
Adds support for the Araneus Alea I USB hardware Random Number
Generator. This RNG creates entropy at a high rate, about 100kb/s.
Signed-off-by: Bob Ham
---
Just a note about the name of the module, I haven't append "-rng" to
the name, like every other module in hw_random, because those modules
45 matches
Mail list logo
