Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

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_iter)) { > > + /* make one iovec available as scatterlist */ > > + err =

Re: [PATCH v2 3/4] crypto: kdf - SP800-108 Key Derivation Function

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

Re: [PATCH v2 3/4] crypto: kdf - SP800-108 Key Derivation Function

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

Re: [PATCH v5 1/3] crypto: Key-agreement Protocol Primitives API (KPP)

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

Re: [RFC] DRBG: which shall be default?

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

Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

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

Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

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

[PATCH] crypto: qat: Remove deprecated create_workqueue

alloc_workqueue replaces deprecated create_workqueue(). The workqueue device_reset_wq has workitem _data->reset_work per adf_reset_dev_data. The workqueue pf2vf_resp_wq is a workqueue for PF2VF responses has workitem _resp->pf2vf_resp_work per pf2vf_resp. The workqueue adf_vf_stop_wq is used to

RE: [PATCH V2 2/2] crypto : async implementation for sha1-mb

-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

[PATCH] crypto : async implementation for sha1-mb

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

Re: [PATCH v3] crypto: rsa - return raw integers for the ASN.1 parser

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

[PATCH v7 0/3] crypto: caam - add support for RSA algorithm

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

[PATCH 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

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

[PATCH 3/3] crypto: caam - add support for RSA algorithm

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

[PATCH 2/3] crypto: scatterwalk - export scatterwalk_pagedone

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

[PATCH v3] crypto: rsa - return raw integers for the ASN.1 parser

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

Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

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

Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations

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

[RFC v4 1/4] block: Introduce blk_bio_map_sg() to map one bio

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

[RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag

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

[RFC v4 3/4] md: dm-crypt: Introduce the bulk mode method when sending request

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

[RFC v4 4/4] crypto: Add the CRYPTO_ALG_BULK flag for ecb(aes) cipher

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

[RFC v4 0/4] Introduce the bulk mode method when sending request to crypto layer

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,

Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations

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

Re: [PATCH 0/2] hwrng: chaoskey - Add support for Araneus Alea I USB RNG

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 -

Re: [PATCH v5 1/9] crypto: shrink hash down to two types

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:

Re: [PATCH v3 8/8] arm64: dts: ls1043a: add crypto node

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

Re: [PATCH 02/28] crypto: omap-sham: Don't idle/start SHA device between Encrypt operations

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

Re: [PATCH v3 1/1] crypto: engine: permit to enqueue ashash_request

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

Re: [PATCH v5 3/9] crypto: add driver-side scomp interface

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) >