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
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
>
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 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 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: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 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 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 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
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 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
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 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 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 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 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: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
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 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
>
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
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
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(+),
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_
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
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
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
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
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 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
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
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
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
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
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
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
-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 :
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.
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
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
45 matches
Mail list logo
