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

Hello Stephan, Did you consider blocking urandom output or returning error until initialized? Given the speed of initialization you report, it shouldn't break any userspace apps while making sure that nobody uses predictable pseudoranom numbers. I was considering asking for patch (or even trying

[PATCH 2/2] Crypto: Add SHA-3 Test's in tcrypt

Added support for SHA-3 algorithm test's in tcrypt module and related test vectors. Signed-off-by: Raveendra Padasalagi --- crypto/tcrypt.c | 53 ++- crypto/testmgr.c | 40 ++ crypto/testmgr.h | 125

[PATCH 0/2] Add SHA-3 algorithm and test vectors.

This patchset adds the implementation of SHA-3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. This patchset also includes changes in tcrypt module

[PATCH 1/2] Crypto: Add SHA-3 hash algorithm

From: Jeff Garzik This patch adds the implementation of SHA3 algorithm in software and it's based on original implementation pushed in patch https://lwn.net/Articles/518415/ with additional changes to match the padding rules specified in SHA-3 specification. Signed-off-by: Jeff

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

On Tue, Jun 14, 2016 at 02:36:54PM +, Benedetto, Salvatore wrote: > > My very first patch used PKCS3 and there were some objections to that. > https://patchwork.kernel.org/patch/8311881/ > > Both Bluetooth or keyctl KEYCTL_DH_COMPUTE would have to first pack the > key to whatever format we

[RESEND PATCH 0/2] hw_random: Add Amlogic Meson SoCs Random Generator driver

NOTE: This is a resent of the DT Bindings and DTSI patches based on the Amlogic DT 64bit GIT pull request from Kevin Hilman at [1]. Changes since v2 at http://lkml.kernel.org/r/1465546915-24229-1-git-send-email-narmstr...@baylibre.com : - Move rng peripheral node into periphs simple-bus node

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

On Tue, Jun 14, 2016 at 04:14:58PM +0300, Tudor Ambarus wrote: > 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

Re: [PATCH v2 0/4] crypto: CTR DRBG - performance improvements

On Tue, Jun 14, 2016 at 07:33:48AM +0200, Stephan Mueller wrote: > Hi, > > The following patch set is aimed to increase the performance of the CTR > DRBG, especially when assembler implementations of the CTR AES mode are > available. > > The patch set increases the performance by 10% for random

RE: [PATCH 2/2] Crypto: Add SHA-3 Test's in tcrypt

Forgot to add Jeff Garzik in the email list. ++ Jeff Garzik. Regards, Raveendra > -Original Message- > From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com] > Sent: 15 June 2016 15:12 > To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux- >

RE: [PATCH 0/2] Add SHA-3 algorithm and test vectors.

Forgot to add Jeff Garzik in the email list. ++ Jeff Garzik. Regards, Raveendra > -Original Message- > From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com] > Sent: 15 June 2016 15:12 > To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux- >

[RESEND PATCH 1/2] dt-bindings: hwrng: Add Amlogic Meson Hardware Random Generator bindings

Acked-by: Rob Herring Signed-off-by: Neil Armstrong --- .../devicetree/bindings/rng/amlogic,meson-rng.txt | 14 ++ 1 file changed, 14 insertions(+) create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt

[RESEND PATCH 2/2] ARM64: dts: meson-gxbb: Add Hardware Random Generator node

Signed-off-by: Neil Armstrong --- arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 + 1 file changed, 5 insertions(+) diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi index 063e3b6..806b903 100644 ---

select on non-existing Kconfig option CRC32C

Hi Hendrik, your patch "s390/crc32-vx: add crypto API module for optimized CRC-32 algorithms" showed up in linux-next today (next-20160615) as commit 364148e0b195. The patch defines the Kconfig option CRYPTO_CRC32_S390 which 'select's CRC32C. However, this should probably

RE: [PATCH 0/2] Add SHA-3 algorithm and test vectors.

The patch set can be fetched from iproc-sha3-v1 branch of https://github.com/Broadcom/arm64-linux.git Regards, Raveendra > -Original Message- > From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com] > Sent: 15 June 2016 15:20 > To: 'Herbert Xu'; 'David S. Miller';

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

On 15 June 2016 at 14:49, Herbert Xu wrote: > On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: >> >> After some investigation, I still think we should divide the bulk >> request from dm-crypt into small request (each one is 512bytes) if >> this algorithm

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

Hi Herbert, On 8 June 2016 at 10:00, Baolin Wang wrote: > 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

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

On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote: > > After some investigation, I still think we should divide the bulk > request from dm-crypt into small request (each one is 512bytes) if > this algorithm is not support bulk mode (like CBC). We have talked > with dm-crypt >

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

On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote: > > But that means we should divide the bulk request into 512-byte size > requests and break up the mapped sg table for each request. Another > hand we should allocate memory for each request in crypto layer, which > dm-crypt have

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

Am Dienstag, 14. Juni 2016, 10:22:15 schrieb Mat Martineau: Hi Mat, > 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

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

On 15 June 2016 at 15:39, Herbert Xu wrote: > On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote: >> >> But that means we should divide the bulk request into 512-byte size >> requests and break up the mapped sg table for each request. Another >> hand we

[PATCH] crypto: fix semicolon.cocci warnings

crypto/drbg.c:1637:39-40: Unneeded semicolon Remove unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci CC: Stephan Mueller Signed-off-by: Fengguang Wu --- drbg.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm

Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra Padasalagi: Hi Raveendra, > From: Jeff Garzik > > This patch adds the implementation of SHA3 algorithm > in software and it's based on original implementation > pushed in patch https://lwn.net/Articles/518415/ with >

Re: [PATCH] crypto: fix semicolon.cocci warnings

Am Mittwoch, 15. Juni 2016, 19:13:25 schrieb kbuild test robot: Hi Fengguang, > crypto/drbg.c:1637:39-40: Unneeded semicolon > > > Remove unneeded semicolon. Thank you! > > Generated by: scripts/coccinelle/misc/semicolon.cocci > > CC: Stephan Mueller > Signed-off-by:

Re: padata - is serial actually serial?

Hi Jason. On Tue, Jun 14, 2016 at 11:00:54PM +0200, Jason A. Donenfeld wrote: > Hi Steffen & Folks, > > I submit a job to padata_do_parallel(). When the parallel() function > triggers, I do some things, and then call padata_do_serial(). Finally > the serial() function triggers, where I complete

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

Changes in v8: - store raw keys on stack - use d_sz instead of n_sz for RSA private exponent - add caam_read_raw_data function for reading RSA modulus raw byte stream as a positive integer. The function updates the n_sz byte length too. Needed because the decryption descriptor uses the RSA

Re: [RESEND PATCH 0/2] hw_random: Add Amlogic Meson SoCs Random Generator driver

Neil Armstrong writes: > NOTE: This is a resent of the DT Bindings and DTSI patches based on the > Amlogic DT 64bit > GIT pull request from Kevin Hilman at [1]. > > Changes since v2 at > http://lkml.kernel.org/r/1465546915-24229-1-git-send-email-narmstr...@baylibre.com

Re: [PATCH 5/7] random: replace non-blocking pool with a Chacha20-based CRNG

On Mon, Jun 13, 2016 at 11:48:37AM -0400, Theodore Ts'o wrote: > The CRNG is faster, and we don't pretend to track entropy usage in the > CRNG any more. > > Signed-off-by: Theodore Ts'o > --- > crypto/chacha20_generic.c | 61 > drivers/char/random.c | 374 >

Re: padata - is serial actually serial?

On 06/15/2016 06:52 AM, Steffen Klassert wrote: Hi Jason. On Tue, Jun 14, 2016 at 11:00:54PM +0200, Jason A. Donenfeld wrote: Hi Steffen & Folks, I submit a job to padata_do_parallel(). When the parallel() function triggers, I do some things, and then call padata_do_serial(). Finally the

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

Am Mittwoch, 15. Juni 2016, 18:17:43 schrieb David Jaša: Hi David, > Hello Stephan, > > Did you consider blocking urandom output or returning error until > initialized? Given the speed of initialization you report, it shouldn't > break any userspace apps while making sure that nobody uses

crypto: gcm - Filter out async ghash if necessary

As it is if you ask for a sync gcm you may actually end up with an async one because it does not filter out async implementations of ghash. This patch fixes this by adding the necessary filter when looking for ghash. Cc: sta...@vger.kernel.org Signed-off-by: Herbert Xu

Re: select on non-existing Kconfig option CRC32C

On 06/15/16 03:00, Andreas Ziegler wrote: > Hi Hendrik, > > your patch "s390/crc32-vx: add crypto API module for optimized CRC-32 > algorithms" showed up in linux-next today (next-20160615) as commit > 364148e0b195. > > The patch defines the Kconfig option CR

Re: select on non-existing Kconfig option CRC32C

Hi Andreas, On Wed, Jun 15, 2016 at 12:00:59PM +0200, Andreas Ziegler wrote: > > your patch "s390/crc32-vx: add crypto API module for optimized CRC-32 > algorithms" showed up in linux-next today (next-20160615) as commit > 364148e0b195. > > The patc

[PATCH v8 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 v8 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 v8 3/3] crypto: caam - add support for RSA algorithm

Add RSA support to caam driver. Initial author is Yashpal Dutta . Signed-off-by: Tudor Ambarus --- drivers/crypto/caam/Kconfig | 12 + drivers/crypto/caam/Makefile | 4 + drivers/crypto/caam/caampkc.c | 693

Re: [PATCH 2/7] crypto: marvell: Check engine is not already running when enabling a req

On Wed, 15 Jun 2016 21:15:29 +0200 Romain Perier wrote: > Adding BUG_ON() macro to be sure that the step operation is not about > to activate a request on the engine if the corresponding engine is > already processing a crypto request. This is helpful when the

[PATCH 6/7] crypto: marvell: Adding load balancing between engines

This commits adds support for fine grained load balancing on multi-engine IPs. The engine is pre-selected based on its current load and on the weight of the crypto request that is about to be processed. The global crypto queue is also moved to each engine. These changes are useful for preparing

[PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req

Actually the only way to access the tdma chain is to use the 'req' union from a mv_cesa_{ablkcipher,ahash}. This will soon become a problem if we want to handle the TDMA chaining vs standard/non-DMA processing in a generic way (with generic functions at the cesa.c level detecting whether the

[PATCH 5/7] crypto: marvell: Adding a complete operation for async requests

So far, the 'process' operation was used to check if the current request was correctly handled by the engine, if it was the case it copied information from the SRAM to the main memory. Now, we split this operation. We keep the 'process' operation, which still checks if the request was correctly

[PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests

Adding a TDMA descriptor at the end of the request for copying the output IV vector via a DMA transfer. This is required for processing cipher requests asynchroniously in chained mode, otherwise the content of the IV vector will be overwriten for each new finished request. Signed-off-by: Romain

[PATCH 0/7] Chain crypto requests together at the DMA level

The Cryptographic Engines and Security Accelerators (CESA) supports the TDMA chained mode support. When this mode is enabled and crypto requests are chained at the DMA level, multiple crypto requests can be handled by the hardware engine without requiring any software intervention. This approach

[PATCH 7/7] crypto: marvell: Add support for chaining crypto requests in TDMA mode

The Cryptographic Engines and Security Accelerators (CESA) supports the Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests can be chained and processed by the hardware without software interferences. This mode was already activated, however the crypto requests were not chained

[PATCH 1/7] crypto: marvell: Add a macro constant for the size of the crypto queue

Adding a macro constant to be used for the size of the crypto queue, instead of using a numeric value directly. It will be easier to maintain in case we add more than one crypto queue of the same size. Signed-off-by: Romain Perier ---

[PATCH 2/7] crypto: marvell: Check engine is not already running when enabling a req

Adding BUG_ON() macro to be sure that the step operation is not about to activate a request on the engine if the corresponding engine is already processing a crypto request. This is helpful when the support for chaining crypto requests will be added. Instead of hanging the system when the engine

Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests

On Wed, 15 Jun 2016 21:15:30 +0200 Romain Perier wrote: > Adding a TDMA descriptor at the end of the request for copying the > output IV vector via a DMA transfer. This is required for processing > cipher requests asynchroniously in chained mode, otherwise the

Re: [PATCH 1/7] crypto: marvell: Add a macro constant for the size of the crypto queue

On Wed, 15 Jun 2016 21:15:28 +0200 Romain Perier wrote: > Adding a macro constant to be used for the size of the crypto queue, > instead of using a numeric value directly. It will be easier to > maintain in case we add more than one crypto queue of the same

Re: [PATCH 5/7] crypto: marvell: Adding a complete operation for async requests

On Wed, 15 Jun 2016 21:15:32 +0200 Romain Perier wrote: > So far, the 'process' operation was used to check if the current request > was correctly handled by the engine, if it was the case it copied > information from the SRAM to the main memory. Now, we split

Re: [PATCH 6/7] crypto: marvell: Adding load balancing between engines

On Wed, 15 Jun 2016 21:15:33 +0200 Romain Perier wrote: > This commits adds support for fine grained load balancing on > multi-engine IPs. The engine is pre-selected based on its current load > and on the weight of the crypto request that is about to be

Re: [PATCH 4/7] crypto: marvell: Moving the tdma chain out of mv_cesa_tdma_req

On Wed, 15 Jun 2016 21:15:31 +0200 Romain Perier wrote: > Actually the only way to access the tdma chain is to use the 'req' union Currently, ... > from a mv_cesa_{ablkcipher,ahash}. This will soon become a problem if we > want to handle the TDMA chaining vs

Re: [PATCH 3/7] crypto: marvell: Copy IV vectors by DMA transfers for acipher requests

On Wed, 15 Jun 2016 21:15:30 +0200 Romain Perier wrote: > @@ -135,23 +140,23 @@ static int mv_cesa_ablkcipher_process(struct > crypto_async_request *req, > { > struct ablkcipher_request *ablkreq = ablkcipher_request_cast(req); > struct

Re: [PATCH 7/7] crypto: marvell: Add support for chaining crypto requests in TDMA mode

On Wed, 15 Jun 2016 21:15:34 +0200 Romain Perier wrote: > The Cryptographic Engines and Security Accelerators (CESA) supports the > Multi-Packet Chain Mode. With this mode enabled, multiple tdma requests > can be chained and processed by the hardware without