Am Dienstag, 7. Juni 2016, 17:28:07 schrieb Mat Martineau:
Hi Mat,
> > + used = ctx->used;
> > +
> > + /* convert iovecs of output buffers into scatterlists */
> > + while (iov_iter_count(&msg->msg_iter)) {
> > + /* make one iovec available as scatterlist */
> > + err =
Am Mittwoch, 8. Juni 2016, 11:13:34 schrieb Herbert Xu:
Hi Herbert,
> OK. I don't think the RNG API really guarantees that you can do
> in-place generation anyway. So don't even bother checking for
> src == dst.
Ok, I will remove the check.
>
> When you submit this again can you please send i
On Thu, Jun 02, 2016 at 05:12:20PM +0200, Stephan Mueller wrote:
>
> The KDFs are usually used for output sizes between one and 4 keys. So,
> commonly it is expected that not more than 200 or 300 bytes are generated by
> one call. But you cannot be sure how much data a user wants. The spec allows
On Thu, Jun 02, 2016 at 12:06:48PM +, Benedetto, Salvatore wrote:
>
> Off the top of my head, with ECDH when the user gets a EGAIN, he wants
> to reset the secret key only, not the params.
I don't see any performance benefit in changing one and not the
other. Besides, you could always check t
On Thu, Jun 02, 2016 at 02:06:55PM +0200, Stephan Mueller wrote:
>
> I am working on it. During the analysis, I saw, however, that the DRBG
> increments the counter before the encryption whereas the the CTR mode
> increments it after the encryption.
>
> I could of course adjust the handling in t
Hi Herbert,
On 7 June 2016 at 22:16, Herbert Xu wrote:
> On Tue, Jun 07, 2016 at 08:17:05PM +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 intermediat
On Wed, Jun 08, 2016 at 08:49:55AM +0800, Herbert Xu wrote:
> On Tue, Jun 07, 2016 at 03:03:11PM -0700, Greg KH wrote:
> >
> > Ok, but usually drivers/usb/misc/ patches go through my tree :)
>
> Sorry. But I do wonder whether this driver should be moved as
> it is just an hwrng device like every
On Tue, Jun 07, 2016 at 03:03:11PM -0700, Greg KH wrote:
>
> Ok, but usually drivers/usb/misc/ patches go through my tree :)
Sorry. But I do wonder whether this driver should be moved as
it is just an hwrng device like every other driver under hw_random,
except for the fact that it happens to be
Stephan,
On Sat, 14 May 2016, Tadeusz Struk wrote:
From: Stephan Mueller
This patch adds the user space interface for asymmetric ciphers. The
interface allows the use of sendmsg as well as vmsplice to provide data.
This version has been rebased on top of 4.6 and a few chackpatch issues
have
On Tue, Jun 07, 2016 at 06:53:45PM +0800, Herbert Xu wrote:
> On Fri, Jun 03, 2016 at 12:13:06PM +0100, Bob Ham wrote:
> > Two patches to add support for the Araneus Alea I USB RNG to the
> > chaoskey driver. The first simply includes the Alea I as a device,
> > the second fixes an issue with the
alloc_workqueue replaces deprecated create_workqueue().
The workqueue device_reset_wq has workitem &reset_data->reset_work per
adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for
PF2VF responses has workitem &pf2vf_resp->pf2vf_resp_work per pf2vf_resp.
The workqueue adf_vf_stop_wq
-Original Message-
From: Herbert Xu [mailto:herb...@gondor.apana.org.au]
Sent: Tuesday, June 7, 2016 3:35 AM
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
; Megha Dey
Subject: Re: [PATCH V2
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
Am Dienstag, 7. Juni 2016, 17:21:09 schrieb Tudor Ambarus:
Hi Tudor,
> Return the raw key with no other processing so that the caller
> can copy it or MPI parse it, etc.
>
> The scope is to have only one ANS.1 parser for all RSA
> implementations.
>
> Update the RSA software implementation so t
Depends on:
[PATCH v3] crypto: rsa - return raw integers for the ASN.1 parser
Changes in v7:
- sync with ASN.1 parser
Changes in v6:
- write descriptor PDB fields with inline append
- move Protocol Data Block (pdb) structures to pdb.h
- move setting of PDB fields in new functions
- unmap sec4_sg_
This patch adds the function scatterwalk_sg_copychunks which writes
a chunk of data from a scatterwalk to another scatterwalk.
It will be used by caam driver to remove the leading zeros
for the output data of the RSA algorithm, after the computation completes.
Signed-off-by: Tudor Ambarus
---
cr
Add RSA support to caam driver.
Coauthored-by: Yashpal Dutta
Signed-off-by: Tudor Ambarus
---
drivers/crypto/caam/Kconfig | 12 +
drivers/crypto/caam/Makefile | 4 +
drivers/crypto/caam/caampkc.c | 637 ++
drivers/crypto/caam/caampkc.h
Used in caam driver. Export the symbol since the caam driver
can be built as a module.
Signed-off-by: Tudor Ambarus
---
crypto/scatterwalk.c | 5 +++--
include/crypto/scatterwalk.h | 2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/crypto/scatterwalk.c b/crypto/scatte
Return the raw key with no other processing so that the caller
can copy it or MPI parse it, etc.
The scope is to have only one ANS.1 parser for all RSA
implementations.
Update the RSA software implementation so that it does
the MPI conversion on top.
Signed-off-by: Tudor Ambarus
---
crypto/rsa
On Tue, Jun 07, 2016 at 08:17:05PM +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 06/07/2016 02:52 PM, Tero Kristo wrote:
On 07/06/16 13:08, Herbert Xu wrote:
On Wed, Jun 01, 2016 at 06:03:52PM -0500, Dave Gerlach wrote:
On 06/01/2016 04:53 AM, Grygorii Strashko wrote:
On 06/01/2016 11:56 AM, Tero Kristo wrote:
From: Lokesh Vutla
Calling runtime PM API for every block
In dm-crypt, it need to map one bio to scatterlist for improving the
hardware engine encryption efficiency. Thus this patch introduces the
blk_bio_map_sg() function to map one bio with scatterlists.
Signed-off-by: Baolin Wang
---
block/blk-merge.c | 19 +++
include/linux/b
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
can increase the size of the request by merging request rather than
In now dm-crypt code, it is ineffective to map one segment (always one
sector) of one bio with just only one scatterlist at one time for hardware
crypto engine. Especially for some encryption mode (like ecb or xts mode)
cooperating with the crypto engine, they just need one initial IV or null
IV in
Since the ecb(aes) cipher does not need to handle the IV things for encryption
or decryption, that means it can support for bulk block when handling data.
Thus this patch adds the CRYPTO_ALG_BULK flag for ecb(aes) cipher to improve
the hardware aes engine's efficiency.
Signed-off-by: Baolin Wang
This patchset will check if the cipher can support bulk mode, then dm-crypt
will handle different ways to send requests to crypto layer according to
cipher mode. For bulk mode, we can use sg table to map the whole bio and
send all scatterlists of one bio to crypto engine to encrypt or decrypt,
whic
On 07/06/16 13:08, Herbert Xu wrote:
On Wed, Jun 01, 2016 at 06:03:52PM -0500, Dave Gerlach wrote:
On 06/01/2016 04:53 AM, Grygorii Strashko wrote:
On 06/01/2016 11:56 AM, Tero Kristo wrote:
From: Lokesh Vutla
Calling runtime PM API for every block causes serious perf hit to
crypto operation
On Fri, Jun 03, 2016 at 12:13:06PM +0100, Bob Ham wrote:
> Two patches to add support for the Araneus Alea I USB RNG to the
> chaoskey driver. The first simply includes the Alea I as a device,
> the second fixes an issue with the timeout on the first read.
>
> Bob Ham (2):
> hwrng: chaoskey - A
On Thu, Jun 02, 2016 at 01:28:55PM +0100, Giovanni Cabiddu wrote:
> Move hash to 0xe to free up the space for acomp/scomp
>
> Signed-off-by: Giovanni Cabiddu
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herber
On Thu, Jun 02, 2016 at 01:48:38PM +0800, Geliang Tang wrote:
> Remove unused header cpumask.h from crypto/ablkcipher.c.
>
> Signed-off-by: Geliang Tang
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pub
On Thu, May 19, 2016 at 06:11:49PM +0300, Horia Geantă wrote:
> LS1043A has a SEC v5.4 security engine.
> For now don't add rtic or sec_mon subnodes, since these features
> haven't been tested yet.
>
> Signed-off-by: Horia Geantă
Patch applied. Thanks.
--
Email: Herbert Xu
Home Page: http://g
On Wed, Jun 01, 2016 at 11:56:02AM +0300, Tero Kristo wrote:
> From: Lokesh Vutla
>
> Algorithms can be registered only once. So skip registration of
> algorithms if already registered (i.e. in case we have two AES cores
> in the system.)
>
> Signed-off-by: Lokesh Vutla
> Signed-off-by: Tero Kr
On Wed, Jun 01, 2016 at 06:03:52PM -0500, Dave Gerlach wrote:
> On 06/01/2016 04:53 AM, Grygorii Strashko wrote:
> >On 06/01/2016 11:56 AM, Tero Kristo wrote:
> >>From: Lokesh Vutla
> >>
> >>Calling runtime PM API for every block causes serious perf hit to
> >>crypto operations that are done on a
On Thu, Jun 02, 2016 at 07:53:49PM -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 Thu, Jun 02, 2016 at 07:53:50PM -0700, Megha Dey wrote:
>
> + struct ahash_alg *shash = crypto_ahash_alg(tfm);
>
> /* alignment is to be done by multi-buffer crypto algorithm if needed */
>
> - return shash->finup(desc, NULL, 0, req->result);
> + return shash->finup(desc);
On Thu, Jun 02, 2016 at 03:13:32PM +0200, LABBE Corentin wrote:
>
> static int omap_aes_prepare_req(struct crypto_engine *engine,
> - struct ablkcipher_request *req)
> + struct crypto_async_request *areq)
> {
> + struct ablkcipher_reques
On Thu, Jun 02, 2016 at 01:28:57PM +0100, Giovanni Cabiddu wrote:
>
> @@ -96,6 +116,31 @@ struct crypto_acomp *crypto_alloc_acomp(const char
> *alg_name, u32 type,
> }
> EXPORT_SYMBOL_GPL(crypto_alloc_acomp);
>
> +struct acomp_req *acomp_request_alloc(struct crypto_acomp *acomp, gfp_t gfp)
> +
37 matches
Mail list logo