On Thu, Aug 18, 2016 at 11:11:01PM -0700, David Miller wrote:
> From: Hariprasad Shenai
> Date: Wed, 17 Aug 2016 12:33:02 +0530
>
> > This patch series adds support for Chelsio Crypto driver.
>
> Herbert, what do you want to do with this? I can push it via
> net-next if you like.
Sure thing,
On Wed, Aug 17, 2016 at 12:33:05PM +0530, Hariprasad Shenai wrote:
> The Chelsio's Crypto Hardware can perform the following operations:
> SHA1, SHA224, SHA256, SHA384 and SHA512, HMAC(SHA1), HMAC(SHA224),
> HMAC(SHA256), HMAC(SHA384), HAMC(SHA512), AES-128-CBC, AES-192-CBC,
> AES-256-CBC, AES-128-
From: Hariprasad Shenai
Date: Wed, 17 Aug 2016 12:33:02 +0530
> This patch series adds support for Chelsio Crypto driver.
Herbert, what do you want to do with this? I can push it via
net-next if you like.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of
On Thu, Aug 18, 2016 at 10:49:47PM -0400, Theodore Ts'o wrote:
>
> That really depends on the system. We can't assume that people are
> using systems with a 100Hz clock interrupt. More often than not
> people are using tickless kernels these days. That's actually the
> problem with changing /dev
On 19/08/2016 00:42, Wei Yongjun wrote:
> Add the missing unlock before return from function sun4i_hash()
> in the error handling case.
>
> Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
> Signed-off-by: Wei Yongjun
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 1 +
>
On Thu, Aug 18, 2016 at 08:39:23PM +0200, Pavel Machek wrote:
>
> But this is the scary part. Not limited to ssh. "We perform the
> largest ever network survey of TLS and SSH servers and present
> evidence that vulnerable keys are surprisingly widespread. We find
> that 0.75% of TLS certificates s
Add the missing unlock before return from function sun4i_hash()
in the error handling case.
Fixes: 477d9b2e591b ("crypto: sun4i-ss - unify update/final function")
Signed-off-by: Wei Yongjun
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/cr
Increase value of supported key sizes for qat_aes_xts.
aes-xts keys consists of keys of equal size concatenated.
Reported-by: Wenqian Yu
Signed-off-by: Giovanni Cabiddu
---
drivers/crypto/qat/qat_common/qat_algs.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drive
On Thu 2016-08-18 13:27:12, Theodore Ts'o wrote:
> On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
> >
> > Actually.. I'm starting to believe that getting enough entropy before
> > userspace starts is more important than pretty much anything else.
> >
> > We only "need" 64-bits of e
On Wed, Aug 17, 2016 at 11:42:55PM +0200, Pavel Machek wrote:
>
> Actually.. I'm starting to believe that getting enough entropy before
> userspace starts is more important than pretty much anything else.
>
> We only "need" 64-bits of entropy, AFAICT. If it passes statistical
> tests, I'd use it.
On Wed, Aug 17, 2016 at 09:05:51PM +0530, PrasannaKumar Muralidharan wrote:
> This patch adds support for hardware random number generator present in
> JZ4780 SoC.
>
> Signed-off-by: PrasannaKumar Muralidharan
> ---
> .../devicetree/bindings/rng/ingenic,jz4780-rng.txt | 12 +++
Acked-by: Rob He
Currently, very few RNG drivers support single byte reads using the
->read() interface. Of the 14 drivers in drivers/char/hw_random that
support this interface only three of these actually support max == 1.
The other behaviours vary between return 0, return 2, return 4 and return
-EIO).
This is no
On 18/08/16 12:53, LABBE Corentin wrote:
On Thu, Aug 18, 2016 at 10:44:18AM +0530, PrasannaKumar Muralidharan wrote:
+static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+ struct jz4780_rng *jz4780_rng = container_of(rng, struct jz4780_rng,
+
So far, we used a dedicated dma pool to copy the result of outer IV for
cipher requests. Instead of using a dma pool per outer data, we prefer
use a common dma pool that contains the part of the SRAM that is likely
to be used by the 'complete' operation, later. In this way, any type of
result can b
Currently, the driver breaks chain for all kind of hash requests in order
to don't override intermediate states of partial ahash updates. However,
some final ahash requests can be directly processed by the engine, and
so without intermediate state. This is typically the case for most for
the HMAC r
This series contain performance improvement regarding ahash requests.
So far, ahash requests were systematically not chained at the DMA level.
However, in some case, like this is the case by using IPSec, some ahash
requests can be processed directly by the engine, and don't have
intermediaire parti
On Thu, Aug 18, 2016 at 10:44:18AM +0530, PrasannaKumar Muralidharan wrote:
> >> +static int jz4780_rng_read(struct hwrng *rng, void *buf, size_t max, bool
> >> wait)
> >> +{
> >> + struct jz4780_rng *jz4780_rng = container_of(rng, struct jz4780_rng,
> >> +
Am Mittwoch, 17. August 2016, 15:09:11 CEST schrieb Tapas Sarangi:
Hi Tapas,
> Is that all the authenc() ciphers, or only some of them ? In my patch
I have not yet had the chance to fully dissect the authenc issue yet.
> where I had disabled .fips_allowed are mostly authenc() ciphers with
> cbc
18 matches
Mail list logo
