From: Eric Biggers
To help avoid confusion, add a comment to ghash-generic.c which explains
the convention that the kernel's implementation of GHASH uses.
Also update the Kconfig help text and module descriptions to call GHASH
a "hash function" rather than a "message digest", since the latter
no
On Fri, Jul 19, 2019 at 09:30:20PM +, Pascal Van Leeuwen wrote:
>
> Still, it seems rather odd to on the one hand acknowledge the fact that there
> is
> hardware out there with these limitations, and add specific support for
> that, and
> on the other hand burden their drivers with impleme
>
> Hmm, NIST SP 800-38D actually defines GHASH to take one argument, same as the
> Linux version. So even outside Linux, there is no consensus on whether
> "GHASH"
> refers to the one argument or two argument versions.
>
Funny, I just stumbled upon that 2007 NIST specification myself minutes a
> > It's a universal keyed hash. Which you could use as a MAC, although,
> > admittedly,
> > it would be rather weak, which is why the tag is usually additionally
> > encrypted.
> > (which you could do externally, knowing that that's needed with GHASH)
> > In any case, the crypto API's ghash does
On Fri, Jul 19, 2019 at 02:48:11PM -0700, Eric Biggers wrote:
> >
> > > So are you proposing that it be renamed? Or are you proposing that a
> > > multi
> > > argument hashing API be added? Or are you proposing that universal
> > > functions
> > > not be exposed through the crypto API? What s
On Fri, Jul 19, 2019 at 08:49:02PM +, Pascal Van Leeuwen wrote:
> Hi Eric,
>
> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org
> > On Behalf Of Eric Biggers
> > Sent: Friday, July 19, 2019 9:57 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org; Her
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Eric Biggers
> Sent: Friday, July 19, 2019 10:07 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu ;
> David S. Miller
> Subject: Re: generic ahash question
>
> On Fri, Jul 19, 2019
Hi Eric,
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Eric Biggers
> Sent: Friday, July 19, 2019 9:57 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu ;
> da...@davemloft.net
> Subject: Re: ghash
>
> Hi Pascal,
>
> On Fri, J
Hi Ard,
> -Original Message-
> From: Ard Biesheuvel
> Sent: Friday, July 19, 2019 7:15 PM
> To: Pascal Van Leeuwen
> Cc: Herbert Xu ; Milan Broz
> ; Horia Geanta ; linux-
> cry...@vger.kernel.org; dm-de...@redhat.com
> Subject: Re: xts fuzz testing and lack of ciphertext stealing suppor
On Fri, Jul 19, 2019 at 07:33:30PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org
> > On Behalf Of Eric Biggers
> > Sent: Friday, July 19, 2019 6:23 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org; Herbert Xu ;
> >
Hi Pascal,
On Fri, Jul 19, 2019 at 07:26:02PM +, Pascal Van Leeuwen wrote:
> > -Original Message-
> > From: linux-crypto-ow...@vger.kernel.org
> > On Behalf Of Eric Biggers
> > Sent: Friday, July 19, 2019 6:16 PM
> > To: Pascal Van Leeuwen
> > Cc: linux-crypto@vger.kernel.org; Herbe
The pull request you sent on Fri, 19 Jul 2019 11:12:06 +0800:
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/dd4542d2823ac55cb86450960423f55e818aa182
Thank you!
--
Deet-doot-dot, I am a bot
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Eric Biggers
> Sent: Friday, July 19, 2019 6:23 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu ;
> David S. Miller
> Subject: Re: generic ahash question
>
> On Fri, Jul 19, 2019
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Eric Biggers
> Sent: Friday, July 19, 2019 6:16 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu ;
> da...@davemloft.net
> Subject: Re: ghash
>
> On Fri, Jul 19, 2019 at 02:05:01PM
With the removal of the padata timer, padata_do_serial no longer
needs special CPU handling, so remove it.
Signed-off-by: Daniel Jordan
Cc: Herbert Xu
Cc: Steffen Klassert
Cc: linux-crypto@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
---
kernel/padata.c | 23 +++
1 file
On 7/18/2019 5:49 PM, Iuliana Prodan wrote:
> Moved to a common location the symbols shared by all CAAM drivers (jr,
> qi, qi2).
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
> ---
> This patch depends on series:
> https://patchwork.kernel.org/project/linux-crypto/list/?series=147
On 7/18/2019 2:29 PM, Vakul Garg wrote:
> While running ipsec processing for traffic through multiple network
> interfaces, it is observed that caam driver gets less time to poll
> responses from caam block compared to ethernet driver. This is because
> ethernet driver has as many napi instances pe
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> To be consistent with other CAAM modules, caamhash should return 0
> instead of -ENODEV in case CAAM has no MDHA.
>
> Based on commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to
> libraries")
> the value returned by entry point is never
On Fri, Jul 19, 2019 at 02:41:03PM +, Pascal Van Leeuwen wrote:
> Hi,
>
> I recall reading somewhere in the Linux Crypto documentation that support for
> finup() and digest()
> calls were explicitly added to support hardware that couldn't handle seperate
> init/update/final
> calls so they c
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> To know if a registration succeeded added a new struct,
> caam_akcipher_alg, that keeps, also, the registration status.
> This status is updated in caam_pkc_init and verified in
> caam_pkc_exit to unregister an algorithm.
>
Fixes: 1b46c90c8e00 ("crypto
On Fri, Jul 19, 2019 at 02:05:01PM +, Pascal Van Leeuwen wrote:
> Hi,
>
> While implementing GHASH support for the inside-secure driver and wondering
> why I couldn't get
> the test vectors to pass I have come to the conclusion that ghash-generic.c
> actually does *not*
> implement GHASH at
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Commit 1b46c90c8e00 ("crypto: caam - convert top level drivers to libraries")
> changed entry and exit points behavior for caamalg,
> caamalg_qi, caamalg_qi2, caamhash, caampkc, caamrng.
>
> For example, previously caam_pkc_init() and caam_pkc_exit() w
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Herbert Xu
> Sent: Friday, July 19, 2019 4:58 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; David S. Miller
> Subject: Re: generic ahash question
>
> On Fri, Jul 19, 2019 at 02:41:03PM +0
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check the return value of the hardware registration for caam_rng and free
> resources in case of failure.
>
> Fixes: 6e4e603a9 ("crypto: caam - Dynamic memory allocation for caam_rng_ctx
> object")
This should be:
Fixes: e24f7c9e87d4 ("crypto: caam -
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Update share descriptor for rfc4106 to skip instructions in case
> cryptlen is zero. If no instructions are jumped the DECO hangs and a
> timeout error is thrown.
>
> Signed-off-by: Iuliana Prodan
> ---
> drivers/crypto/caam/caamalg_desc.c | 46
> ++
On Fri, Jul 19, 2019 at 03:06:38PM +, Horia Geanta wrote:
>
> Herbert, is it worth having these checks moved to crypto API,
> so they could be shared b/w all implementations?
Yes this should be turned into a inline helper.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check zero-length input, for skcipher algorithm, to solve the extra
> tests. This is a valid operation, therefore the API will return no error.
>
> Signed-off-by: Iuliana Prodan
Reviewed-by: Horia Geantă
Horia
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
[...]
> --- a/drivers/crypto/caam/common_if.c
> +++ b/drivers/crypto/caam/common_if.c
> @@ -66,6 +66,23 @@ int check_rfc4106_authsize(unsigned int authsize)
> }
> EXPORT_SYMBOL(check_rfc4106_authsize);
>
> +/*
> + * validate assoclen for RFC4106/RFC45
On Fri, Jul 19, 2019 at 02:41:03PM +, Pascal Van Leeuwen wrote:
>
> So I'm guessing there must be some flags that I can set to indicate I'm not
> supporting seperate
> init/update/final calls so that testmgr skips those specific tests? Which
> flag(s) do I need to set?
All implementations m
On Fri, Jul 19, 2019 at 10:37:21AM -0400, Daniel Jordan wrote:
>
> If I'm not missing anything, still looks like get_cpu() and reorder_via_wq no
> longer have an effect with this patch and can be removed.
You're right that they're not needed. But we shouldn't mix clean-ups
with substantial change
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
[...]
> diff --git a/drivers/crypto/caam/caamalg_qi.c
> b/drivers/crypto/caam/caamalg_qi.c
> index 46097e3..5f9b14a 100644
> --- a/drivers/crypto/caam/caamalg_qi.c
> +++ b/drivers/crypto/caam/caamalg_qi.c
> @@ -18,6 +18,7 @@
> #include "qi.h"
> #includ
Hi,
I recall reading somewhere in the Linux Crypto documentation that support for
finup() and digest()
calls were explicitly added to support hardware that couldn't handle seperate
init/update/final
calls so they could at least be used with e.g. the IPsec stack. I also noticed
that testmgr *do
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> Check key length to solve the extra tests that expect -EINVAL to be
> returned when the key size is not valid.
>
> Validated AES keylen for skcipher and ahash.
>
Also aead was updated.
> The check_aes_keylen function is added in a common file, to be
On Thu, Jul 18, 2019 at 11:01:46PM +0800, Herbert Xu wrote:
> @@ -376,9 +325,8 @@ void padata_do_serial(struct padata_priv *padata)
>
> cpu = get_cpu();
>
> - /* We need to run on the same CPU padata_do_parallel(.., padata, ..)
> - * was called on -- or, at least, enqueue the pad
On Thu, Jul 18, 2019 at 10:56:34PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:27:30AM -0400, Daniel Jordan wrote:
> >
> > That's what I expected when I first saw it too, but nr_cpumask_bits is
> > returned
> > to signal the end of the iteration. The patch always passes 0 for the
> > '
On Thu, Jul 18, 2019 at 10:49:50PM +0800, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:25:15AM -0400, Daniel Jordan wrote:
> >
> > Which memory barrier do you mean? I think you're referring to the one that
> > atomic_inc might provide? If so, the memory model maintainers can correct
> > me
> >
Hi,
While implementing GHASH support for the inside-secure driver and wondering why
I couldn't get
the test vectors to pass I have come to the conclusion that ghash-generic.c
actually does *not*
implement GHASH at all. It merely implements the underlying chained GF
multiplication, which,
I und
Add support of printing the dpseci frame queue statistics using debugfs.
Signed-off-by: Vakul Garg
---
drivers/crypto/caam/Kconfig | 11 +
drivers/crypto/caam/Makefile | 1 +
drivers/crypto/caam/caamalg_qi2.c| 5 +++
drivers/crypto/caam/caamalg_qi2.h| 2 +
drivers
On 7/19/2019 2:58 AM, Iuliana Prodan wrote:
> From: Horia Geantă
>
> Update alginfo struct to keep both virtual and dma key addresses,
> so that descriptors have them at hand.
> One example where this is needed is in the xcbc(aes) shared descriptors,
> which are updated in current patch.
> Anothe
On 7/18/2019 6:11 PM, Herbert Xu wrote:
> On Thu, Jul 18, 2019 at 10:59:07PM +0800, Herbert Xu wrote:
>>
>> So I presume the driver does enforce the limit. Please actually
>> state that in the commit description for future reference.
>
> Also have you looked at whether other drivers would be affe
Check assoclen to solve the extra tests that expect -EINVAL to be
returned when the associated data size is not valid.
Validated assoclen for RFC4543 which expects an assoclen
of 16 or 20, the same as RFC4106.
Based on seqiv, IPsec ESP and RFC4543/RFC4106 the assoclen is sizeof
IP Header (spi, seq
Validated assoclen for RFC4543 which expects an assoclen
of 16 or 20, the same as RFC4106.
Based on seqiv, IPsec ESP and RFC4543/RFC4106 the assoclen is sizeof
IP Header (spi, seq_no, extended seq_no) and IV len. This can be 16 or
20 bytes.
Signed-off-by: Iuliana Prodan
---
drivers/crypto/bcm/ci
42 matches
Mail list logo
