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
The jent_get_nstime() function uses __getnstimeofday() to get
something similar to a 64-bit nanosecond counter. As we want
to get rid of struct timespec to fix the y2038 overflow,
this patch changes the code to use __getnstimeofday64()
instead, which returns a timespec64 structure.
Nothing changes
David Jaša wrote:
>
> BTW when looking at an old BSI's issue with Linux urandom that Jarod
> Wilson tried to solve with this series:
> https://www.spinics.net/lists/linux-crypto/msg06113.html
> I was thinking:
> 1) wouldn't it help for large urandom consumers if kernel created a DRBG
> instance f
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_secret() - It allows the user to set his secret, also
referred to as his private key, along with the parame
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 v8:
* set_secret accept a b
* 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 |4 +
crypto/ecc.c| 1018
* 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 | 4 +
crypto/dh.c | 189 ++
crypto/dh_helper.c |
Hi Stephan,
thank you for your thorough reply,
On St, 2016-06-15 at 18:58 +0200, Stephan Mueller wrote:
> 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
On Fri, 17 Jun 2016 13:24:09 +0200
Romain Perier wrote:
> Now that crypto requests are chained together at the DMA level, we
> increase the size of the crypto queue for each engine. The result is
> that as the backlog list is reached later, it does not stop the crypto
> stack from sending asychro
On Fri, 17 Jun 2016 13:24:08 +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 software
> intervention. This mode was
On Fri, 17 Jun 2016 13:24:07 +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 processed.
> The global crypto queue is als
On Fri, 17 Jun 2016 13:24:06 +0200
Romain Perier wrote:
> Currently the crypto requests were sent to engines sequentially.
> This commit moves the SRAM I/O operations from the prepare to the step
> functions. It provides flexibility for future works and allow to prepare
> a request while the engi
On Fri, 17 Jun 2016 13:24:05 +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 this
> operation. We keep the 'proce
On Fri, 17 Jun 2016 13:24:04 +0200
Romain Perier wrote:
> Currently, 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 (wit
On Fri, 17 Jun 2016 13:24:03 +0200
Romain Perier wrote:
> Add a TDMA descriptor at the end of the request for copying the
> output IV vector via a DMA transfer. This is a good way for offloading
> as much as processing as possible to the DMA and the crypto engine.
> This is also required for proc
On Fri, 17 Jun 2016 13:24:02 +0200
Romain Perier wrote:
> So far, the way that the type of a TDMA operation was checked was
> wrong. We have to use the type mask in order to get the right part of
> the flag containing the type of the operation.
>
> Signed-off-by: Romain Perier
Acked-by: Boris
On Fri, 17 Jun 2016 13:24:01 +0200
Romain Perier wrote:
> Add a BUG_ON() call when the driver tries to launch a crypto request
> while the engine is still processing the previous one. This replaces
> a silent system hang by a verbose kernel panic with the associated
> backtrace to let the user kn
On Fri, 17 Jun 2016 13:24:00 +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 size.
>
> Signed-off-by: Romain Perier
On 6/16/2016 4:33 PM, Tudor Ambarus wrote:
> EXTRA_CFLAGS is still supported but its usage is deprecated.
>
> Signed-off-by: Tudor Ambarus
Reviewed-by: Horia Geantă
> ---
> drivers/crypto/caam/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/crypto/ca
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 han
Add a BUG_ON() call when the driver tries to launch a crypto request
while the engine is still processing the previous one. This replaces
a silent system hang by a verbose kernel panic with the associated
backtrace to let the user know that something went wrong in the CESA
driver.
Signed-off-by: R
Currently, 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 requ
Add a TDMA descriptor at the end of the request for copying the
output IV vector via a DMA transfer. This is a good way for offloading
as much as processing as possible to the DMA and the crypto engine.
This is also required for processing multiple cipher requests
in chained mode, otherwise the con
Now that crypto requests are chained together at the DMA level, we
increase the size of the crypto queue for each engine. The result is
that as the backlog list is reached later, it does not stop the crypto
stack from sending asychronous requests, so more cryptographic tasks
are processed by the en
Currently the crypto requests were sent to engines sequentially.
This commit moves the SRAM I/O operations from the prepare to the step
functions. It provides flexibility for future works and allow to prepare
a request while the engine is running.
Signed-off-by: Romain Perier
---
drivers/crypto/
So far, the way that the type of a TDMA operation was checked was wrong.
We have to use the type mask in order to get the right part of the flag
containing the type of the operation.
Signed-off-by: Romain Perier
---
drivers/crypto/marvell/tdma.c | 5 +++--
1 file changed, 3 insertions(+), 2 dele
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
---
drivers/crypto/marvell/cesa.c | 5 -
1 file changed, 4 in
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
intervention. This mode was already activated, however the crypto
requests were not chained t
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
required to allow chaini
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 li
Hello,
Le 15/06/2016 23:43, Boris Brezillon a écrit :
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 har
++ Stephan Mueller
Regards,
Raveendra
> -Original Message-
> From: Raveendra Padasalagi [mailto:raveendra.padasal...@broadcom.com]
> Sent: 17 June 2016 10:31
> To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux-
> ker...@vger.kernel.org
> Cc: Jon Mason; Florian Fainelli;
Am Freitag, 17. Juni 2016, 11:19:58 schrieb Stephan Mueller:
Hi Stephan,
> Am Freitag, 17. Juni 2016, 12:16:19 schrieb Dan Carpenter:
>
> Hi Dan,
>
> > We accidentally return PTR_ERR(NULL) which is success but we should
> > return -ENOMEM.
> >
> > Fixes: 355912852115 ('crypto: drbg - use CTR A
Am Freitag, 17. Juni 2016, 12:16:19 schrieb Dan Carpenter:
Hi Dan,
> We accidentally return PTR_ERR(NULL) which is success but we should
> return -ENOMEM.
>
> Fixes: 355912852115 ('crypto: drbg - use CTR AES instead of ECB AES')
> Signed-off-by: Dan Carpenter
Acked-by: Stephan Mueller
That p
We accidentally return PTR_ERR(NULL) which is success but we should
return -ENOMEM.
Fixes: 355912852115 ('crypto: drbg - use CTR AES instead of ECB AES')
Signed-off-by: Dan Carpenter
diff --git a/crypto/drbg.c b/crypto/drbg.c
index ded8638..6872d15 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
35 matches
Mail list logo
