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
-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
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
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
> -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
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]
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
,
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 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
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
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
(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 ++-
, 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
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
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
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
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
> -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 ;
&
> -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
>
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: 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
> -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: 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
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: 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
> -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: 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: 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: 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: 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 ; linux-crypto@vger.kernel.org;
> linux-ke
> -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-
>
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: 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.
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: 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..
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
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
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
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
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 |
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
>
> -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
> -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;
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'
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
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
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
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));
> +
> -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
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
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
> -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
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
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
> -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
&
> -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: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 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 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 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
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: 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
> -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...
> On Monday, April 1, 2019 10:04 AM, Vitaly Chikunov wrote:
>
> > >
> > > Can you elaborate on why you want to use Streebog? When we added
> > > Speck, we explained in great detail why it was useful from a
> > > technical perspective (before Adiantum was ready). I don't see any such
> explanation
ream, meaning you run at the speed of the round-trip latency instead
of the throughput, which is typically one to two orders of a magnitude slower)
And in the odd case you do need it, you can just grab it from the data buffer
yourself.
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines
> > Herbert, can you explain what users actually rely on the next IV being
> returned?
> > I don't know all the historical context behind this.
>
> Chaining by reusing the output IV has always been part of the API.
>
Then where is this specified? Because I read through all the Kernel Crypto
API doc
> > Then where is this specified? Because I read through all the Kernel
> > Crypto API documentation multiple times, but I have not been able to
> > find ANY reference to any output IV being stored anywhere.
> > Yes, I can infer from the source code that this is what the standard
> > CBC wrapper do
>
> What we could do is have the user specify an explicit flag saying
> that they do not care about the output IV. You could then skip the
> output IV step in your driver.
>
That would work for me, if the maintainers would be OK with adding
such flags.
Also, as a heads up - just to get other peopl
> One person's "corner case" is another person's "use case". Once you
>
That argument works both ways though. Someone else's use case may be
getting decent performance from an accelerator for a specific
application, which has worked fine for years but is now broken to
comply with some (for them!)
> I really shouldn't have to say this, but just because something hasn't
> been
> reported doesn't mean it's not a real problem. Someone could easily be
> affected
> by one of these bugs where crypto drivers produce the wrong output, and
> never
> notice it because their use case doesn't involve c
presence of an IOMMU? Considering pretty much every device
driver would need to do that?
Does anyone know which function(s) to use for that?
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
cles to be contiguous, but there is some problem in some
other location in the API causing this to not always be the case"?
I took a quick peek at skcipher.c, which is a design unfamiliar to
me, but the first thing that strikes me is that there is an
"skcipher_walk_async", that inde
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Wednesday, April 17, 2019 10:24 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu
>
> Subject: Re: Question regarding crypto scatterlists / testmgr
>
> Hi
y itself. However, whomever
> created the inside-secure driver was under the impression that this
> was not supposed to be the case. And I don't know who's right or
> wrong there, but from a side discussion with Ard I got the impression
> that the Crypto API should fix this up
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Wednesday, April 17, 2019 11:43 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; Herbert Xu
>
> Subject: Re: Question regarding crypto scatterlists / testmgr
>
> Hi
> -Original Message-
> From: Ard Biesheuvel [mailto:ard.biesheu...@linaro.org]
> Sent: Wednesday, April 17, 2019 11:43 PM
> To: Pascal Van Leeuwen
> Cc: Eric Biggers ; linux-crypto@vger.kernel.org;
> Herbert Xu
> Subject: Re: Question regarding crypto scatterlists
or us this is the natural way to do the AEAD transform so no one ever
just thought twice about that. Also can't find anything specific in the docs.
Even so, for the in-place case, checking the AAD data would ensure the crypto
implementation didn't *accidentally* corrupt it ...
Pas
plan on working on improving performance
and adding support for additional algorithms our hardware supports.
Anyone out there willing to contribute?
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of antoine.ten...@bootlin.com
> Sent: Tuesday, April 30, 2019 3:27 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org; antoine.ten...@bo
o help resolve those issues
BTW: if there are no issues and everything worked fine I'm also
interested to hear about that :-)
Regards,
Pascal
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
Tel. : +31 (0)73 65 81 900
www.insidesecure.com
in
physical/device memory.
The latter should be guaranteed by the kernel allocator.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines, Inside Secure
Tel. : +31 (0)73 65 81 900
www.insidesecure.com
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@google.com]
> Sent: Thursday, May 23, 2019 8:59 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto-ow...@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +,
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@google.com]
> Sent: Thursday, May 23, 2019 9:06 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto-ow...@vger.kernel.org; Herbert Xu
>
> Subject: Re: testmgr question
>
> On Thu, May 23, 2019 at 07:01:46A
> -Original Message-
> From: Eric Biggers [mailto:ebigg...@kernel.org]
> Sent: Thursday, May 23, 2019 10:06 PM
> To: Pascal Van Leeuwen
> Cc: linux-crypto@vger.kernel.org
> Subject: Re: another testmgr question
>
> On Thu, May 23, 2019 at 01:07:25PM +,
the length
whatsoever and only know the expected sum. In which case that would
validate that a zero-length file is indeed what you should have ...
Still - is that something the crypto API is *currently* being used for?
And if not, do we ever *intend* to use it for something like that?
If not,
s particular case they are tests intended for development
and not for production use, so I guess it's OK to keep them for that.
Although I would like to see the testing continue if a test fails,
such that I have the option to ignore the ones I don't care about ...
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com
; Christophe
>
Cristophe,
Thanks for the help! I just had a quick look and this indeed looks like a good
solution that I could use for my driver as well.
(Actually, just before reading your mail I had a discussion with a coworker
here and he came up with the exact same solution. But still: than
the common code so that
> implementations need to handle less, e.g. see how
> https://patchwork.kernel.org/patch/10949189/ proposed to check the message
> length alignment for skciphers (though that particular patch is broken as-
> is).
>
That goes without saying.
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com
e async calls (_aio) though? Because otherwise they shouldn't
end up being hardware accelerated anyway ...
Regards,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Inside Secure
www.insidesecure.com
101 - 200 of 395 matches
Mail list logo
