Re: (none)

Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu: Hi Herbert, > Jeffrey Walton wrote: > > Please forgive my ignorance here... > > > > I have test system with a VIA C7-M processor and PM-400 chipset. This > > is one of those Thin Client/Internet of Things processor and

Re: (none)

Jeffrey Walton wrote: > Please forgive my ignorance here... > > I have test system with a VIA C7-M processor and PM-400 chipset. This > is one of those Thin Client/Internet of Things processor and chipsets > I test security libraries on (like OpenSSL, Cryptlib and Crypto++).

[RFC v3 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. For avoiding the duplicated code in __blk_bios_map_sg() function, add one parameter to distinguish

[RFC v3 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 v3 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,

[RFC v3 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 v3 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

[no subject]

Please forgive my ignorance here... I have test system with a VIA C7-M processor and PM-400 chipset. This is one of those Thin Client/Internet of Things processor and chipsets I test security libraries on (like OpenSSL, Cryptlib and Crypto++). The processor includes the Padlock extensions.

Re: [PATCH] KEYS: Add placeholder for KDF usage with DH

On Tue, 31 May 2016, David Howells wrote: > Hi James, > > > Could you pass this along to Linus as soon as possible, please? This > > alters a new keyctl function added in the current merge window to allow for > > a future extension planned for the next merge window. > > Is this likely to go to

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

On 30 May 2016 at 21:32, 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

Re: [PATCH v2 2/2] crypto: omap: convert to the new cryptoengine API

On 30 May 2016 at 21:32, LABBE Corentin wrote: > Since the crypto engine has been converted to use crypto_async_request > instead of ablkcipher_request, minor changes are needed to use it. > > Signed-off-by: LABBE Corentin > --- >

Re: [PATCH v2 0/4] hw rng support for NSP SoC

On Tue, May 31, 2016 at 10:09:39AM -0700, Florian Fainelli wrote: > > FYI, ARM Device Tree patches usually go via ARM SoC pull requests, so it > is best if this is planned in advance. Can you make sure you document > that there could be a merge conflict in your pull request to Linus? Sure I can

Re: [PATCH v4 0/5] /dev/random - a new approach

I'll be a while going through this. I was thinking about our earlier discussion where I was hammering on the point that compressing entropy too early is a mistake, and just now realized that I should have given you credit for my recent 4.7-rc1 patch 2a18da7a. The hash function ("good, fast AND

[PATCH 1/2] crypto : stylistic cleanup in sha1-mb

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

[PATCH 2/2] 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

[PATCH 0/2] async implementation for sha1-mb

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

Re: [PATCH 1/7] crypto : stylistic cleanup in sha1-mb

On Tue, 2016-05-31 at 16:13 +0800, Herbert Xu wrote: > On Thu, May 19, 2016 at 05:43:04PM -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

Re: [PATCH 0/5] refactor mpi_read_from_buffer()

Herbert Xu writes: > On Thu, May 26, 2016 at 11:19:50PM +0200, Nicolai Stange wrote: >> mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a >> fair amount of common code. >> >> This patchset attempts to rewrite mpi_read_from_buffer() in

[PATCH v4 4/5] crypto: LRNG - enable compile

Add LRNG compilation support. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 10 ++ crypto/Makefile | 1 + 2 files changed, 11 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 1d33beb..9aaf96c 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig

[PATCH v4 1/5] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel code paths outside the drbg.c file. Signed-off-by: Stephan Mueller --- crypto/drbg.c | 11 +-- include/crypto/drbg.h | 7 +++ 2 files changed, 12 insertions(+), 6 deletions(-)

[PATCH v4 0/5] /dev/random - a new approach

Hi Herbert, Ted, The following patch set provides a different approach to /dev/random which I call Linux Random Number Generator (LRNG) to collect entropy within the Linux kernel. The main improvements compared to the legacy /dev/random is to provide sufficient entropy during boot time as well as

[PATCH v4 2/5] random: conditionally compile code depending on LRNG

When selecting the LRNG for compilation, disable the legacy /dev/random implementation. The LRNG is a drop-in replacement for the legacy /dev/random which implements the same in-kernel and user space API. Only the hooks of /dev/random into other parts of the kernel need to be disabled.

[PATCH v4 5/5] random: add interrupt callback to VMBus IRQ handler

The Hyper-V Linux Integration Services use the VMBus implementation for communication with the Hypervisor. VMBus registers its own interrupt handler that completely bypasses the common Linux interrupt handling. This implies that the interrupt entropy collector is not triggered. This patch adds

[PATCH v4 3/5] crypto: Linux Random Number Generator

The LRNG with all its properties is documented in [1]. This documentation covers the functional discussion as well as testing of all aspects of entropy processing. In addition, the documentation explains the conducted regression tests to verify that the LRNG is API and ABI compatible with the

Re: [PATCH v6 6/6] crypto: AF_ALG - add support for key_id

Hi Mat, On 05/25/2016 05:45 PM, Mat Martineau wrote: > > On Sat, 14 May 2016, Tadeusz Struk wrote: > >> diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c >> index e00793d..6733df1 100644 >> --- a/crypto/algif_akcipher.c >> +++ b/crypto/algif_akcipher.c >> +static int

Re: [PATCH v2 0/4] hw rng support for NSP SoC

On 05/31/2016 03:19 AM, Herbert Xu wrote: > On Fri, May 27, 2016 at 06:10:37AM -0400, Yendapally Reddy Dhananjaya Reddy > wrote: >> This patchset contains the hw random number generator support for the >> Broadcom's NSP SoC. The block is similar to the block available in >> bcm2835 with different

Re: [PATCH] KEYS: Add optional key derivation parameters for DH

On Thu, 26 May 2016, David Howells wrote: Mat Martineau wrote: +struct keyctl_kdf_params { + char *name; + __u8 reserved[32]; /* Reserved for future use, must be 0 */ +}; + #endif /* _LINUX_KEYCTL_H */ diff --git a/security/keys/compat.c

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

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 set the parameters known to both parties involved in the key-agreement

[PATCH v7 3/3] crypto: kpp - Add ECDH software support

* Implement ECDH under kpp API * Provide ECC software support for curve P-192 and P-256. * Add kpp test for ECDH with data generated by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig |5 + crypto/Makefile |3 +

[PATCH v7 2/3] crypto: kpp - Add DH software implementation

* Implement MPI based Diffie-Hellman under kpp API * Test provided uses data generad by OpenSSL Signed-off-by: Salvatore Benedetto --- crypto/Kconfig | 8 ++ crypto/Makefile | 2 + crypto/dh.c | 223

[PATCH v7 0/3] Key-agreement Protocol Primitives (KPP) API

Hi Herb, the following patchset introduces a new API for abstracting key-agreement protocols such as DH and ECDH. It provides the primitives required for implementing the protocol, thus the name KPP (Key-agreement Protocol Primitives). Regards, Salvatore Changes from v6: * Remove len parameter

[PATCH v4 01/10] crypto: shrink hash down to two types

Move hash to 0xe to free up the space for acomp/scomp/qdecomp 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

[PATCH v4 05/10] crypto: acomp - add support for lzo via scomp

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

[PATCH v4 09/10] crypto: acomp - add support for deflate via scomp

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

[PATCH v4 02/10] crypto: add asynchronous compression api

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

[PATCH v4 04/10] crypto: add quick decompression api

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 --- crypto/Makefile |

[PATCH v4 08/10] crypto: acomp - add support for 842 via scomp

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

[PATCH v4 07/10] crypto: acomp - add support for lz4hc via scomp

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

[PATCH v4 00/10] crypto: asynchronous compression api

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

[PATCH v4 03/10] crypto: add driver-side scomp interface

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

[PATCH v4 06/10] crypto: acomp - add support for lz4 via scomp

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

[PATCH v4 10/10] crypto: acomp - update testmgr with support for acomp

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

Re: Test AEAD/authenc algorithms from userspace

Am Dienstag, 31. Mai 2016, 17:22:12 schrieb Harsh Jain: Hi Harsh, > Hi, > > 1) User can use libkcapi to write program for finup/digest. > 2) No, kernel test for finup (not sure). > 3) We can test all callback of new hash tfm drivers added in kernel. > 4) My driver had issue in finup path which

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

The SP800-108 compliant Key Derivation Function is implemented as a random number generator considering that it behaves like a deterministic RNG. All three KDF types specified in SP800-108 are implemented. The code comments provide details about how to invoke the different KDF types.

[PATCH v2 1/4] crypto: add template handling for RNGs

This patch adds the ability to register templates for RNGs. RNGs are "meta" mechanisms using raw cipher primitives. Thus, RNGs can now be implemented as templates to allow the complete flexibility the kernel crypto API provides. Signed-off-by: Stephan Mueller ---

[PATCH v2 4/4] crypto: kdf - enable compilation

Include KDF into Kconfig and Makefile for compilation. Signed-off-by: Stephan Mueller --- crypto/Kconfig | 7 +++ crypto/Makefile | 1 + 2 files changed, 8 insertions(+) diff --git a/crypto/Kconfig b/crypto/Kconfig index 1d33beb..89c1891 100644 --- a/crypto/Kconfig

[PATCH v2 0/4] crypto: Key Derivation Function (SP800-108)

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 RNG where the key material is used as a seed. With the KDF implemented as a

[PATCH v2 2/4] crypto: kdf - add known answer tests

Add known answer tests to the testmgr for the KDF (SP800-108) cipher. Signed-off-by: Stephan Mueller --- crypto/testmgr.c | 167 +++ crypto/testmgr.h | 111 2 files changed, 278

Re: Test AEAD/authenc algorithms from userspace

Hi, 1) User can use libkcapi to write program for finup/digest. 2) No, kernel test for finup (not sure). 3) We can test all callback of new hash tfm drivers added in kernel. 4) My driver had issue in finup path which is not caught by kcapi test program :) regards Harsh Jain regards Harsh Jain

[PATCH] crypto: DRBG - reduce number of setkey calls

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, the CTR DRBG performance increases by more than 150%. Signed-off-by: Stephan

Re: Test AEAD/authenc algorithms from userspace

Am Dienstag, 31. Mai 2016, 16:28:14 schrieb Harsh Jain: Hi Harsh, > Hi Stephen, > > Yes ,It's for Hash. The available API in library for hash update > "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not > trigger driver's digest/finup implementation. We need something like > that >

Re: Test AEAD/authenc algorithms from userspace

Hi Stephen, Yes ,It's for Hash. The available API in library for hash update "_kcapi_md_update" uses "MSG_MORE" flag always set. It will not trigger driver's digest/finup implementation. We need something like that _kcapi_common_accept() send(handle->opfd, buffer, len, 0); ==> flag = 0. It

Re: [PATCH v2 0/4] hw rng support for NSP SoC

On Fri, May 27, 2016 at 06:10:37AM -0400, Yendapally Reddy Dhananjaya Reddy wrote: > This patchset contains the hw random number generator support for the > Broadcom's NSP SoC. The block is similar to the block available in > bcm2835 with different default interrupt mask value. Due to lack of >

Re: [PATCH 0/5] refactor mpi_read_from_buffer()

On Thu, May 26, 2016 at 11:19:50PM +0200, Nicolai Stange wrote: > mpi_read_from_buffer() and mpi_read_raw_data() do almost the same and share a > fair amount of common code. > > This patchset attempts to rewrite mpi_read_from_buffer() in order to implement > it in terms of mpi_read_raw_data(). >

Re: [PATCH 1/2] lib/mpi: mpi_read_raw_data(): purge redundant clearing of nbits

On Thu, May 26, 2016 at 01:05:31PM +0200, Nicolai Stange wrote: > In mpi_read_raw_data(), unsigned nbits is calculated as follows: > > nbits = nbytes * 8; > > and redundantly cleared later on if nbytes == 0: > > if (nbytes > 0) > ... > else > nbits = 0; > > Purge this redundant

Re: [PATCH] hwrng: stm32: fix maybe uninitialized variable warning

On Thu, May 26, 2016 at 11:34:57AM +0200, Maxime Coquelin wrote: > This patch fixes the following warning: > drivers/char/hw_random/stm32-rng.c: In function 'stm32_rng_read': > drivers/char/hw_random/stm32-rng.c:82:19: warning: 'sr' may be used >

Re: [PATCH] lib/mpi: purge mpi_set_buffer()

On Thu, May 26, 2016 at 12:57:50PM +0200, Nicolai Stange wrote: > mpi_set_buffer() has no in-tree users and similar functionality is provided > by mpi_read_raw_data(). > > Remove mpi_set_buffer(). > > Signed-off-by: Nicolai Stange Applied. -- Email: Herbert Xu

Re: [PATCH v3 0/8] crypto: caam - add support for LS1043A SoC

On Thu, May 19, 2016 at 06:06:45PM +0300, Horia Geantă wrote: > v3: > -DT maintainers - please ack patch 8/8 "arm64: dts: ls1043a: add crypto node" > (to go into kernel 4.8 via crypto tree) > -Fixed typo in pdb.h: s/be32/__be32 > -Appended Acks (from v2) into commit messages > -Tested that current

Re: [PATCH 0010/1529] Fix typo

On Sat, May 21, 2016 at 01:36:43PM +0200, Andrea Gelmini wrote: > Signed-off-by: Andrea Gelmini Applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To

Re: [PATCH 19/54] MAINTAINERS: Add file patterns for rng device tree bindings

On Sun, May 22, 2016 at 11:05:56AM +0200, Geert Uytterhoeven wrote: > Submitters of device tree binding documentation may forget to CC > the subsystem maintainer if this is missing. > > Signed-off-by: Geert Uytterhoeven Applied. -- Email: Herbert Xu

Re: [PATCH 0211/1529] Fix typo

On Sat, May 21, 2016 at 02:03:38PM +0200, Andrea Gelmini wrote: > Signed-off-by: Andrea Gelmini Applied. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To

Re: [PATCH] crypto: qat - fix typos sizeof for ctx

On Tue, May 17, 2016 at 10:53:51AM -0700, Tadeusz Struk wrote: > The sizeof(*ctx->dec_cd) and sizeof(*ctx->enc_cd) are equal, > but we should use the correct one for freeing memory anyway. > > Signed-off-by: Tadeusz Struk Applied. -- Email: Herbert Xu

Re: [PATCH] crypto: user - no parsing of CRYPTO_MSG_GETALG

On Mon, May 16, 2016 at 02:53:36AM +0200, Stephan Mueller wrote: > The CRYPTO_MSG_GETALG netlink message type provides a buffer to the > kernel to retrieve information from the kernel. The data buffer will not > provide any input and will not be read. Hence the nlmsg_parse is not > applicable to

Re: [PATCH] crypto: Intel SHA - add MODULE_ALIAS

On Fri, May 13, 2016 at 02:02:00PM +0200, Stephan Mueller wrote: > Add the MODULE_ALIAS for the cra_driver_name of the different ciphers to > allow an automated loading if a driver name is used. > > Signed-off-by: Stephan Mueller Applied. -- Email: Herbert Xu

Re: [PATCH 2/6] crypto: talitos - making mapping helpers more generic

On Fri, May 27, 2016 at 11:32:36AM +0200, Christophe Leroy wrote: > > + sg_count = sg_to_link_tbl_offset(src, sg_count, offset, len, > + >link_tbl[tbl_off]) > + if (sg_count == 1) { > + /* Only one segment now, so no link tbl needed*/ > +

Re: [PATCH] KEYS: Add placeholder for KDF usage with DH

Hi James, > Could you pass this along to Linus as soon as possible, please? This > alters a new keyctl function added in the current merge window to allow for > a future extension planned for the next merge window. Is this likely to go to Linus before -rc2? If not, we'll need to do things

Re: Test AEAD/authenc algorithms from userspace

Am Dienstag, 31. Mai 2016, 14:45:27 schrieb Harsh Jain: Hi Harsh, > Hi, > > Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add > some switch cases in tool to test digest and finup path of crypto > driver. Current implementation triggers only init/update/final. You mean for

Re: Test AEAD/authenc algorithms from userspace

Hi, Thanks Stephen, I will check the same.1 suggestion for kcapi tool. Add some switch cases in tool to test digest and finup path of crypto driver. Current implementation triggers only init/update/final. Regards Harsh Jain On Tue, May 31, 2016 at 2:29 PM, Stephan Mueller

Re: Test AEAD/authenc algorithms from userspace

Am Dienstag, 31. Mai 2016, 14:10:20 schrieb Harsh Jain: Hi Harsh, > Hi, > > You means to say like this > > ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p > 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k >

RE: [PATCH v5 2/3] crypto: kpp - Add DH software implementation

> -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Tuesday, May 31, 2016 7:53 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH v5 2/3] crypto: kpp - Add DH software implementation > >

RE: [PATCH v5 3/3] crypto: kpp - Add ECDH software support

> -Original Message- > From: Herbert Xu [mailto:herb...@gondor.apana.org.au] > Sent: Tuesday, May 31, 2016 7:55 AM > To: Benedetto, Salvatore > Cc: linux-crypto@vger.kernel.org > Subject: Re: [PATCH v5 3/3] crypto: kpp - Add ECDH software support > > On

Re: Test AEAD/authenc algorithms from userspace

Hi, You means to say like this ./kcapi -x 2 -e -c "authenc(hmac(sha1),cbc(aes))" -p 48981da18e4bb9ef7e2e3162d16b19108b19050f66582cb7f7e4b6c873819b71 -k 8d7dd9b0170ce0b5f2f8e1aa768e01e91da8bfc67fd486d081b28254c99eb423 -i 7fbc02ebf5b93322329df9bfccb635af -a afcd7202d621e06ca53b70c2bdff7fb2 -l

Re: [PATCH 1/7] crypto : stylistic cleanup in sha1-mb

On Thu, May 19, 2016 at 05:43:04PM -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

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

On Thu, May 12, 2016 at 06:00:33PM +0300, Tudor Ambarus wrote: > > int rsa_get_n(void *context, size_t hdrlen, unsigned char tag, > const void *value, size_t vlen) > { > struct rsa_key *key = context; > + const char *ptr = value; > + int ret; > > - key->n =

Re: [PATCH v5 3/3] crypto: kpp - Add ECDH software support

On Mon, May 09, 2016 at 10:40:41PM +0100, Salvatore Benedetto wrote: > > + do { > + if (tries++ >= MAX_TRIES) > + goto err_retries; > + > + ecc_point_mult(pk, >g, priv, NULL, curve->p, ndigits); > + > + } while (ecc_point_is_zero(pk)); You might

Re: Test AEAD/authenc algorithms from userspace

Am Dienstag, 31. Mai 2016, 12:31:16 schrieb Harsh Jain: Hi Harsh, > Hi All, > > How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from > userspace program.I check libkcapi library. It has test programs for > GCM/CCM. There are 3 types of approaches to Authenticated Encryption, >

Test AEAD/authenc algorithms from userspace

Hi All, How can we open socket of type "authenc(hmac(sha256),cbc(aes))" from userspace program.I check libkcapi library. It has test programs for GCM/CCM. There are 3 types of approaches to Authenticated Encryption, Which of them is supported in crypto framework. 1) Encrypt-then-MAC (EtM)

Re: [PATCH v5 2/3] crypto: kpp - Add DH software implementation

On Mon, May 09, 2016 at 10:40:40PM +0100, Salvatore Benedetto wrote: > > +static int dh_set_params(struct crypto_kpp *tfm, void *buffer, > + unsigned int len) > +{ > + struct dh_ctx *ctx = dh_get_ctx(tfm); > + struct dh_params *params = (struct dh_params *)buffer; > +

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

On Mon, May 09, 2016 at 10:40:39PM +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