(using what is formally a debug feature).
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 44 ++---
drivers/crypto/inside-secure/safexcel.h | 13 ++
2 files changed, 54 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/inside
want to prevent it from being
a possibility at all. So initialize all error bits to error state, so
that reading stale status information will always result in errors.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_ring.c | 9 +
1 file changed, 5 insertions
aligned boundary. Also ensuring that the
last cacheline of the last buffer is not shared (by overallocating).
This was tested by the customer to solve their coherence problems. It
was also tested by me on a VCU118 board w/ EIP-197c and Macchiatobin.
Signed-off-by: Pascal van Leeuwen
---
drivers
> -Original Message-
> From: Arnd Bergmann
> Sent: Tuesday, October 22, 2019 6:17 PM
> To: Pascal Van Leeuwen
> Cc: Herbert Xu ; David S. Miller
> ; Antoine
> Tenart ; Ard Biesheuvel
> ; Pascal van
> Leeuwen ; linux-crypto@vger.kernel.org;
> linux-ker...
> -Original Message-
> From: Arnd Bergmann
> Sent: Tuesday, October 22, 2019 4:29 PM
> To: Herbert Xu ; David S. Miller
>
> Cc: Arnd Bergmann ; Antoine Tenart
> ; Pascal Van
> Leeuwen ; Ard Biesheuvel
> ; Pascal van
> Leeuwen ; linux-crypto
This fixes a bunch of endianness related sparse warnings reported by the
kbuild test robot as well as Ben Dooks.
Credits for the fix to safexcel.c go to Ben Dooks.
Reported-by: kbuild test robot
Reported-by: Ben Dooks
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 9:47 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> On Mon, 21 Oct 2019 at 21:14, Pas
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 6:15 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> On Mon, 21 Oct 2019 at 17:55, Pas
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 5:32 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> p[
>
> On Mon, 21 Oct 2019 at 17:2
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 2:54 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> On Mon, 21 Oct 2019 at 14:40, Pas
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 1:59 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> On Mon, 21 Oct 2019 at 12:56, Pascal Van Leeuwen
&
> -Original Message-
> From: Ard Biesheuvel
> Sent: Monday, October 21, 2019 2:12 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; herb...@gondor.apana.org.au
> Subject: Re: Key endianness?
>
> On Mon, 21 Oct 2019 at 14:08, Pascal Van Leeuwen
&
27;ll probably still have to swap the bytes
within words to get those into the correct order towards the HW.
Which is not very convenient for fields crossing byte boundaries.
(I'd probably want to use the byte swapping facilities of my HW
for that and not the CPU)
Regards,
Pascal van Leeuwen
Si
but that would require touching a lot
of legacy code (unless I use a C11 anonymous union ... not sure
if that would be allowed?) and IMHO is a bit silly.
Is there some way of telling sparse to _not_ check for "correct"
use of these functions for a certain variable?
Regards,
Pascal van Lee
> -Original Message-
> From: Pascal Van Leeuwen
> Sent: Thursday, October 17, 2019 9:46 PM
> To: 'Ben Dooks (Codethink)' ;
> 'linux-ker...@lists.codethink.co.uk'
>
> Cc: 'Antoine Tenart' ; 'Herbert Xu'
> ;
> 'Davi
he byte order of this key
data is _CPU byte order_ or always some _fixed byte order_ (e.g. as per
algorithm specification).
I know I have some customers using big-endian CPU's, so I do care, but
I unfortunately don't have any platform available to test this with.
Regards,
Pascal van
turn PTR_ERR_OR_ZERO(ctx->kaes);
> }
Thanks for spotting, but a similar patch has already been applied.
So this patch is obsolete now.
>
> static void safexcel_xcbcmac_cra_exit(struct crypto_tfm *tfm)
> --
> 2.7.4
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
> -Original Message-
> From: Pascal Van Leeuwen
> Sent: Thursday, October 17, 2019 7:14 PM
> To: 'Ben Dooks (Codethink)' ; linux-
> ker...@lists.codethink.co.uk
> Cc: Antoine Tenart ; Herbert Xu
> ; David S. Miller ; linux-
> cry...@vger.kernel.org; linu
firmware */
> - for (i = 0; i < fw->size / sizeof(u32); i++)
> + for (i = 0; i < fw->size / sizeof(__be32); i++)
> writel(be32_to_cpu(data[i]),
> -priv->base + EIP197_CLASSIFICATION_RAMS + i *
> sizeof(u32));
> +
int ofreg_rc = -EINVAL; /* Default safe value */
> #endif
>
> static int __init safexcel_init(void)
> --
> 2.23.0
Actually those variables have already disappeared from the
cryptodev tree due to an earlier patch by Arnd.
So this patch won't apply anyway.
I'll see if I can spin a patch that makes safexcel_pci_remove
static.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
safexcel_pci_remove() is only used locally in the module and not exported,
so added a static function specifier.
This fixes a sparse issue reported by Ben Dooks.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion
Always take the zero length hash value for SM3 from the local constant
to avoid a reported build error when SM3 is configured to be a module.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_hash.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff
t CRYPTO_CHACHA20POLY1305
> select CRYPTO_SHA3
> + select CRYPTO_SM3
> help
> This driver interfaces with the SafeXcel EIP-97 and EIP-197
> cryptographic
> engines designed by Inside Secure. It currently accelerates DES, 3DES
> and
>
I'
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Pascal Van Leeuwen
> Sent: Tuesday, October 8, 2019 9:57 AM
> To: Ard Biesheuvel
> Cc: YueHaibing ; herb...@gondor.apana.org.au;
> da...@davemloft.net;
> pascalv...@gmail.com;
> -Original Message-
> From: Arnd Bergmann
> Sent: Thursday, October 17, 2019 3:48 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller ; Bjorn Helgaas ;
> Pascal van Leeuwen
> ; Kelsey Skunberg ; linux-
> cry
Miller ; Bjorn Helgaas
> Cc: Arnd Bergmann ; Pascal Van Leeuwen
> ; Pascal van
> Leeuwen ; Kelsey Skunberg ;
> linux-
> cry...@vger.kernel.org; linux-ker...@vger.kernel.org;
> linux-...@vger.kernel.org
> Subject: [PATCH 3/3] crypto: inside-secure - Remove #ifdef checks
>
Subject: [PATCH -next] crypto: Use PTR_ERR_OR_ZERO in
> safexcel_xcbcmac_cra_init()
>
> Use PTR_ERR_OR_ZERO rather than if(IS_ERR(...)) + PTR_ERR
>
> Signed-off-by: YueHaibing
>
Acked-by: Pascal van Leeuwen
> ---
> drivers/crypto/inside-secure/safexcel_hash.c |
here? It is also FIPS
> compliant and has less latency than TPM RNG. :-) If we go with this
> route, lets pick the HRNG that performs best.
>
There's certification and certification. Not all certificates are
created equally. But if it matches your specific requirements, why not.
There's a _lot_ of HW out there that's not x86 though ...
And: is RDRAND certified for _all_ x86 processors? Or just Intel?
Or perhaps even only _specific (server) models_ of CPU's?
I also know for a fact that some older AMD processors had a broken
RDRAND implementation ...
So the choice really should be up to the application or user.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
d,
but would Joe Random User?)
> Please remember that a trusted key is not a TPM key. The reality
> distortion field is strong here it seems.
>
Agree. But you should not mess with the possibility to generate
keys based on _just_ the TPM RNG _where that is required_ (and
perhaps _only_ where that is required, if possible)
> /Jarkko
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
existing_ use cases.
Having said all that, generating _true_ entropy (and, importantly,
ensuring it cannot be manipulated) is a very complicated subject and
considering how all encryption security ultimately depends on the
quality of the random numbers used for key material, I would not
trust a
t u8 *key,
> goto badkey;
> break;
> default:
> - dev_err(priv->dev, "aead: unsupported hash algorithmn");
> + dev_err(priv->dev, "aead: unsupported hash algorithm\n");
> goto bad
> -Original Message-
> From: Joe Perches
> Sent: Tuesday, October 8, 2019 10:29 AM
> To: Pascal Van Leeuwen ; Colin King
> ;
> Antoine Tenart ; Herbert Xu
> ; David S .
> Miller ; linux-crypto@vger.kernel.org
> Cc: kernel-janit...@vger.kernel.org; linux-ker..
otted, but the fix is not correct.
What actually happened here is that a \ got accidentally deleted,
there should have been a "\n" at the end of the line ...
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
> -Original Message-
> From: Ard Biesheuvel
> Sent: Tuesday, October 8, 2019 9:35 AM
> To: Pascal Van Leeuwen
> Cc: YueHaibing ; herb...@gondor.apana.org.au;
> da...@davemloft.net;
> pascalv...@gmail.com; antoine.ten...@bootlin.com;
> linux-crypto@vger.
ed by Inside Secure. It currently accelerates DES, 3DES
> and
> --
> 2.7.4
>
But ... I don't really want to build SM3 into the kernel for all Inside
Secure drivers, since in the majority of cases, the HW will not actually
support SM3 and I don't want to bloat the kernel imag
> -Original Message-
> From: Arnd Bergmann
> Sent: Monday, September 30, 2019 10:12 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller ; Pascal van Leeuwen
> ; Ard
> Biesheuvel ; Eric Biggers ;
> linux-
>
> -Original Message-
> From: Arnd Bergmann
> Sent: Monday, September 30, 2019 2:15 PM
> To: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller
> Cc: Arnd Bergmann ; Pascal Van Leeuwen
> ; Pascal van
> Leeuwen ; linux-crypto@vger.kernel.org;
> linux-ke
> -Original Message
> From: Linus Torvalds
> Sent: Friday, September 27, 2019 6:24 PM
> To: Pascal Van Leeuwen
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; Linux ARM ;
> Herbert Xu
> ; David Miller ; Greg KH
> ; Jason A
> -Original Message-
> From: Arnd Bergmann
> Sent: Monday, September 30, 2019 2:15 PM
> To: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller
> Cc: Arnd Bergmann ; Pascal Van Leeuwen
> ; Pascal
> van Leeuwen ; Ard Biesheuvel
> ; Eric Biggers
> ; linux
> -Original Message-
> From: Dave Taht
> Sent: Friday, September 27, 2019 1:14 AM
> To: Pascal Van Leeuwen
> Cc: Jason A. Donenfeld ; Ard Biesheuvel
> ;
> Linux Crypto Mailing List ; linux-arm-kernel
> ker...@lists.infradead.org>; Herbert Xu ; David
&
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf
> Of Pascal Van Leeuwen
> Sent: Friday, September 27, 2019 12:44 PM
> To: Linus Torvalds
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; Linux ARM ;
&g
> -Original Message-
> From: Linus Torvalds
> Sent: Friday, September 27, 2019 4:54 AM
> To: Pascal Van Leeuwen
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; Linux ARM ;
> Herbert Xu
> ; David Miller ; Greg KH
> ; Jason A
> -Original Message-
> From: Linus Torvalds
> Sent: Friday, September 27, 2019 4:06 AM
> To: Pascal Van Leeuwen
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; Linux ARM ;
> Herbert Xu
> ; David Miller ; Greg KH
> ; Jason A
e thing. It's actively detrimental for "I have no HW acceleration".
>
You keep asserting that with no evidence whatsoeever.
> And apparently it's not optimal for you guys either.
>
True, but I accept the fact that it needs to be that way because some
_other_
> -Original Message-
> From: Linus Torvalds
> Sent: Thursday, September 26, 2019 6:35 PM
> To: Pascal Van Leeuwen
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; Linux ARM ;
> Herbert Xu
> ; David Miller ; Greg KH
> ; Jason A
> -Original Message-
> From: Ard Biesheuvel
> Sent: Thursday, September 26, 2019 4:59 PM
> To: Pascal Van Leeuwen
> Cc: Linux Crypto Mailing List
> Subject: Re: Chacha-Poly performance on ARM64
>
> On Thu, 26 Sep 2019 at 16:55, Pascal Van Leeuwen
> wro
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf
> Of Ard Biesheuvel
> Sent: Thursday, September 26, 2019 4:53 PM
> To: Pascal Van Leeuwen
> Cc: Jason A. Donenfeld ; Linux Crypto Mailing List cry...@vger.kernel.org>; linux-arm-kernel
search in the codebase but couldn't
find any ARM64 optimized version ...
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
> -Original Message-
> From: Ard Biesheuvel
> Sent: Thursday, September 26, 2019 3:16 PM
> To: Pascal Van Leeuwen
> Cc: Jason A. Donenfeld ; Linux Crypto Mailing List cry...@vger.kernel.org>; linux-arm-kernel
> ;
> Herbert Xu ; David Miller ;
> Greg KH
>
> -Original Message-
> From: Jason A. Donenfeld
> Sent: Thursday, September 26, 2019 1:07 PM
> To: Pascal Van Leeuwen
> Cc: Ard Biesheuvel ; Linux Crypto Mailing List
> cry...@vger.kernel.org>; linux-arm-kernel
> ;
> Herbert Xu ; David Miller ;
&
o now, and extend that later for async accelerators once people
> realize that we really do need that as well.
>
What's wrong with a step-by-step approach though? i.e. merge it with
library calls now and then gradually work towards the goal of integrating
(a tweaked version of) the Crypto API where that actually makes sense?
Rome wasn't built in one day either ...
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
initely in the embedded (networking) space.
And it *will* be much faster than the embedded CPU next to it, so it will
be worth using it for something like bulk packet encryption.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
t that surely won't consume
excessive power like AVX512)
> But even if you're right that it might be a power advantage on some
> platform, that wouldn't make it an advantage on other platforms. Maybe
> it could be done as a config option where you can opt in to the async
> inte
Due to the addition of Chacha20-Poly1305 support to the inside-secure
driver, it now depends on CRYPTO_CHACHA20POLY1305. Added reference.
changes since v1:
- added missing dependency to crypto/Kconfig
changes since v2:
- nothing
changes since v3:
- nothing
Signed-off-by: Pascal van Leeuwen
, and this is actually possible as long as cryptlen is large
enough, so made that possible as well.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 2 +
drivers/crypto/inside-secure/safexcel.h| 8 +
drivers/crypto/inside-secure/safexcel_cipher.c
l hardware)
Pascal van Leeuwen (3):
crypto: inside-secure - Added support for the CHACHA20 skcipher
crypto: inside-secure - Add support for the Chacha20-Poly1305 AEAD
crypto: Kconfig - Add CRYPTO_CHACHA20POLY1305 to CRYPTO_DEV_SAFEXCEL
drivers/crypto/Kconfig | 3 +
generic fallback is compiled as well
changes since v2:
- made switch entry SAFEXCEL_AES explit and added empty default, as
requested by Antoine Tenart. Also needed to make SM4 patches apply.
changes since v3:
- nothing
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c
(Marvell A8K - EIP197b-ieswx), including the crypto
extra tests.
Note that this patchset applies on top of the earlier submitted
"Add support for eip197f_iewc" series.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 69 ++-
the number of ring AIC's present. This allows it to at least function.
(optimization for the future: add ring dispatch functionality in the
interrupt service routine such that multiple rings can be supported from
one ring AIC, allowing all rings to be used)
Signed-off-by: Pascal van Leeuwe
This patch adds support for large EIP197's with a 256 bit wide internal
bus, which affects the format of the result descriptor due to internal
alignment requirements.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 101 +++
dr
h the eip197f_iewc_w8 and eip197c_iewxkbc
configurations on the Xilinx VCU118 development board as well as on the
Macchiatobin board (Marvell A8K/eip197b_ieswx), including the crypto extra
tests.
Pascal van Leeuwen (2):
crypto: inside-secure - Add support for 256 bit wide internal bus
crypto: i
This patch adds support for rfc4106(gcm(aes)) for use with IPsec ESP
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 1 +
drivers/crypto/inside-secure/safexcel_cipher.c | 112
This patch adds support for rfc4309(ccm(aes)) for use with IPsec ESP
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 5 +-
drivers/crypto/inside-secure/safexcel_cipher.c | 165
,
including the testmgr extra tests.
Pascal van Leeuwen (3):
crypto: inside-secure - Added support for the rfc4106(gcm(aes)) AEAD
crypto: inside-secure - Added support for the rfc4543(gcm(aes)) "AEAD"
crypto: inside-secure - Added support for the rfc4309(ccm(aes)) AEAD
drivers/crypto/ins
This patch adds support for rfc4543(gcm(aes)) - i.e. AES-GMAC - for use
with IPsec ESP
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 2 +
drivers/crypto/inside-secure/safexcel_cipher.c | 86
This patch fixed a corner case admin RAM probing issue witnessed on the
Xilinx VCU118 FPGA development board with an EIP197 configuration with
4096 words of admin RAM, of which only 2050 were recognised.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 48
development
board. And since it was a problem with hash table access, it was very
dependent on the actual physical context record DMA buffers being used,
i.e. with some (bad) luck it could seemingly work quit stable for a while.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c
of TRC data RAM and 4096 words of TRC admin RAM on the
Xilinx VCU118 development board as well as on the Macchiatobin board
(Marvell A8K: EIP197b-ieswx w/ 15350 bytes data RAM & 80 words admin RAM),
including the testmgr extra tests.
Pascal van Leeuwen (2):
crypto: inside-secure: [URGENT]
> -Original Message-
> From: Eric Biggers
> Sent: Sunday, September 15, 2019 10:21 PM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; linux-crypto@vger.kernel.org;
> antoine.ten...@bootlin.com; herb...@gondor.apana.org.au; da...@davemloft.net
> Subject: R
This patch adds support for the authenc(hmac(sha1),cbc(des)) aead
changes since v1:
- rebased on top of DES changes made to cryptodev/master
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 1
This patch adds support for the authenc(hmac(sha224),cbc(des)),
authenc(hmac(sha256),cbc(des)), authenc(hmac(sha384),cbc(des))
and authenc(hmac(sha512),cbc(des)) aead's
changes since v1:
- nothing
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c
This patch adds support for the authenc(hmac(sha224),cbc(des3_ede)),
authenc(hmac(sha256),cbc(des3_ede)), authenc(hmac(sha384),cbc(des3_ede))
and authenc(hmac(sha512),cbc(des3_ede)) aead's
changes since v1:
- nothing
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safex
since v1:
- rebased on top of DES changes made to cryptodev/master
Pascal van Leeuwen (3):
crypto: inside-secure - Added support for authenc HMAC-SHA1/DES-CBC
crypto: inside-secure - Added support for authenc HMAC-SHA2/3DES-CBC
crypto: inside-secure - Added support for authenc HMAC-SHA2/DES-CBC
-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 4 +
drivers/crypto/inside-secure/safexcel.h | 4 +
drivers/crypto/inside-secure/safexcel_hash.c | 441 ++-
3 files changed, 436 insertions(+), 13 deletions(-)
diff --git a/drivers
fallback is compiled as well
Pascal van Leeuwen (3):
crypto: inside-secure - Add SHA3 family of basic hash algorithms
crypto: inside-secure - Add HMAC-SHA3 family of authentication
algorithms
crypto: Kconfig - Add CRYPTO_SHA3 to CRYPTO_DEV_SAFEXCEL
drivers/crypto/Kconfig
Due to the addition of SHA3 and HMAC-SHA3 support to the inside-secure
driver, it now depends on CRYPTO_SHA3. Added reference.
changes since v1:
- added missing dependency to crypto/Kconfig
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff
This patch adds support for sha3-224, sha3-256, sha3-384 and sha3-512
basic hashes.
The patch has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development board, including the testmgr extra tests.
changes since v1:
- nothing
Signed-off-by: Pascal van Leeuwen
abovementioned modified testmgr
This patch applies on top of "Add support for SM4 ciphers" and needs to
be applied before "Add (HMAC) SHA3 support".
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 4 +
drivers/crypto/inside-secure/saf
dded empty default, as
requested by Antoine Tenart. Also needed to make SM4 patches apply.
Pascal van Leeuwen (3):
crypto: inside-secure - Added support for the CHACHA20 skcipher
crypto: inside-secure - Add support for the Chacha20-Poly1305 AEAD
crypto: Kconfig - Add CRYPTO_CHACHA20P
/Kconfig so that generic fallback is compiled as well
changes since v2:
- nothing
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 2 +
drivers/crypto/inside-secure/safexcel.h| 8 +
drivers/crypto/inside-secure/safexcel_cipher.c | 276
Due to the addition of Chacha20-Poly1305 support to the inside-secure
driver, it now depends on CRYPTO_CHACHA20POLY1305. Added reference.
changes since v1:
- added missing dependency to crypto/Kconfig
changes since v2:
- nothing
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/Kconfig | 3
generic fallback is compiled as well
changes since v2:
- made switch entry SAFEXCEL_AES explit and added empty default, as
requested by Antoine Tenart. Also needed to make SM4 patches apply.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers
Due to the addition of Chacha20-Poly1305 support to the inside-secure
driver, it now depends on CRYPTO_CHACHA20POLY1305. Added reference.
changes since v1:
- added missing dependency to crypto/Kconfig
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/Kconfig | 3 ++-
1 file changed, 2
This patch adds support for the Chacha20-Poly1305 cipher suite.
It adds both the basic rfc7539(chacha20,poly1305) as well as the
rfc7539esp(chacha20,poly1305) variant for IPsec ESP acceleration.
changes since v1:
- rebased on top of DES changes done to cryptodev/master
Signed-off-by: Pascal van
Added support for the CHACHA20 skcipher algorithm.
Tested on an eip197c-iesb configuration in the Xilinx VCU118 devboard,
passes all testmgr vectors plus the extra fuzzing tests.
changes since v1:
- rebased on top of DES changes done to cryptodev/master
Signed-off-by: Pascal van Leeuwen
applies on top of the earlier submitted
"Add support for the CBCMAC" series.
changes since v1:
- rebased on top of DES library changes done on cryptodev/master
- fixed crypto/Kconfig so that generic fallback is compiled as well
Pascal van Leeuwen (3):
crypto: inside-secure - Added suppo
> -Original Message-
> From: Ard Biesheuvel
> Sent: Friday, September 13, 2019 6:24 PM
> To: Pascal Van Leeuwen
> Cc: Pascal van Leeuwen ; open list:HARDWARE RANDOM
> NUMBER
> GENERATOR CORE ; Antoine Tenart
> ; Herbert Xu ; David
> S. Miller
>
>
on top of the earlier submitted
"Add support for the Chacha20 kcipher and the Chacha20-Poly..." series.
changes since v1:
- incorporated feedback by Antoine Tenart, see individual patches for
details
changes since v2:
- allow compilation if CONFIG_CRYPTO_SM3 is not set
Pascal van
Added support for the hmac(sm3) ahash authentication algorithm
changes since v1:
- added Acked-by tag below, no changes to the source
changes since v2:
- nothing
Acked-by: Antoine Tenart
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 1 +
drivers/crypto
Added testvectors for the hmac(sm3) ahash authentication algorithm
changes since v1 & v2:
-nothing
Signed-off-by: Pascal van Leeuwen
---
crypto/testmgr.c | 6 ++
crypto/testmgr.h | 56
2 files changed, 62 insertions(+)
diff --g
Added support for the SM3 ahash algorithm
changes since v1:
- moved definition of CONTEXT_CONTROL_CRYPTO_ALG_SM3 (0x7) up above 0xf
changes since v2:
- allow compilation if CONFIG_CRYPTO_SM3 is not set
Acked-by: Antoine Tenart
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside
> -Original Message-
> From: Ard Biesheuvel
> Sent: Friday, September 13, 2019 5:27 PM
> To: Pascal van Leeuwen
> Cc: open list:HARDWARE RANDOM NUMBER GENERATOR CORE
> ;
> Antoine Tenart ; Herbert Xu
> ;
> David S. Miller ; Pascal Van Leeuwen
>
>
This patchset adds the remaining authencs with DES or 3DES currently
supported with vectors by testmgr.
The patchset has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development boardi as well as on the Macchiatobin board,
including the testmgr extra tests.
Pascal van
This patch adds support for the authenc(hmac(sha224),cbc(des)),
authenc(hmac(sha256),cbc(des)), authenc(hmac(sha384),cbc(des))
and authenc(hmac(sha512),cbc(des)) aead's
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 4 +
drivers/crypto/inside-s
This patch adds support for the authenc(hmac(sha1),cbc(des)) aead
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 1 +
drivers/crypto/inside-secure/safexcel.h| 1 +
drivers/crypto/inside-secure/safexcel_cipher.c | 45 ++
3
This patch adds support for the authenc(hmac(sha224),cbc(des3_ede)),
authenc(hmac(sha256),cbc(des3_ede)), authenc(hmac(sha384),cbc(des3_ede))
and authenc(hmac(sha512),cbc(des3_ede)) aead's
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c| 4 +
dr
This patch adds support for hmac(sha3-224), hmac(sha3-256), hmac(sha3-384)
and hmac(sha3-512) authentication algorithms.
The patch has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development board, including the testmgr extra tests.
Signed-off-by: Pascal van Leeuwen
This patch adds support for sha3-224, sha3-256, sha3-384 and sha3-512
basic hashes.
The patch has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development board, including the testmgr extra tests.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure
This patchset adds support for all flavours of sha3-xxx and hmac(sha3-xxx)
ahash algorithms.
The patchset has been tested with the eip197c_iewxkbc configuration on the
Xilinx VCU118 development board, including the testmgr extra tests.
Pascal van Leeuwen (2):
crypto: inside-secure - Add SHA3
Added testvectors for the rfc3686(ctr(sm4)) skcipher algorithm
changes since v1:
- nothing
Signed-off-by: Pascal van Leeuwen
---
crypto/testmgr.c | 6 ++
crypto/testmgr.h | 29 +
2 files changed, 35 insertions(+)
diff --git a/crypto/testmgr.c b/crypto
1 - 100 of 395 matches
Mail list logo
