In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
skcipher encrypt and decrypt routines from outside of task or softirq
context.
Signed-off-by: Ard Biesheuvel
---
crypto/skcipher.c | 10 ++
1
The following are the conditions for requesting AES fallback cipher.
- AES-192
- AES-XTS request with len <= 512 byte (Allow messages of length
less than 512 bytes for all other AES encryption algorithms other
than AES XTS)
- AES-XTS request with len > Q
Crypto engine BAM dma does not support 0 length data. Return unsupported
if zero length messages are passed for transformation.
Signed-off-by: Thara Gopinath
---
v5->v6:
- Return 0 for zero length messages instead of -EOPNOTSUPP in the
cipher algorithms as pointed out by Eric B
ECB transformations do not have an IV and hence set the ivsize to 0 for
ecb(aes).
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
index c2f0469ffb22..
ECB/CBC encryption/decryption requires the data to be blocksize aligned.
Crypto engine hangs on non-block sized operations for these algorithms.
Return invalid data if data size is not blocksize aligned for these
algorithms.
Signed-off-by: Thara Gopinath
---
v5->v6:
- Remove the wrong TO
Return unsupported if any three keys are same for DES3 algorithms
since CE does not support this and the operation causes the engine to
hang.
Signed-off-by: Thara Gopinath
---
v6->v7:
- Fixed sparse warning in patch 4 as pointed out by Herbert Xu.
This means the checking if any
Crypto engine does not support key1 = key2 for AES XTS algorithm; the
operation hangs the engines. Return -EINVAL in case key1 and key2 are the
same.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff -
On Sun, Feb 07, 2021 at 09:39:39AM -0500, Thara Gopinath wrote:
>
> + /*
> + * The crypto engine does not support any two keys
> + * being the same for triple des algorithms. The
> + * verify_skcipher_des3_key does not check for all the
> + * below conditions. Return -ENOKEY
The following are the conditions for requesting AES fallback cipher.
- AES-192
- AES-XTS request with len <= 512 byte (Allow messages of length
less than 512 bytes for all other AES encryption algorithms other
than AES XTS)
- AES-XTS request with len > Q
ECB transformations do not have an IV and hence set the ivsize to 0 for
ecb(aes).
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
index d24d96ed5be9..
Crypto engine BAM dma does not support 0 length data. Return unsupported
if zero length messages are passed for transformation.
Signed-off-by: Thara Gopinath
---
v5->v6:
- Return 0 for zero length messages instead of -EOPNOTSUPP in the
cipher algorithms as pointed out by Eric B
Crypto engine does not support key1 = key2 for AES XTS algorithm; the
operation hangs the engines. Return -EINVAL in case key1 and key2 are the
same.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff -
ECB/CBC encryption/decryption requires the data to be blocksize aligned.
Crypto engine hangs on non-block sized operations for these algorithms.
Return invalid data if data size is not blocksize aligned for these
algorithms.
Signed-off-by: Thara Gopinath
---
v5->v6:
- Remove the wrong TO
Return unsupported if any three keys are same for DES3 algorithms
since CE does not support this and the operation causes the engine to
hang.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/crypto/qce/sk
On 2/4/21 7:26 PM, Eric Biggers wrote:
On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
@@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct skcipher_request
*req, int encrypt)
rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
keylen = IS_XTS(rctx->flags
On Thu, Feb 04, 2021 at 07:09:53PM -0500, Thara Gopinath wrote:
> > > @@ -260,6 +261,10 @@ static int qce_skcipher_crypt(struct
> > > skcipher_request *req, int encrypt)
> > > rctx->flags |= encrypt ? QCE_ENCRYPT : QCE_DECRYPT;
> > > keylen = IS_XTS(rctx->flags) ? ctx->enc_keyl
On 2/4/21 5:50 PM, Eric Biggers wrote:
On Thu, Feb 04, 2021 at 04:43:54PM -0500, Thara Gopinath wrote:
+ /*
+* ECB and CBC algorithms require message lengths to be
+* multiples of block size.
+* TODO: The spec says AES CBC mode for certain versions
+* of
Hi Eric,
On 2/4/21 5:48 PM, Eric Biggers wrote:
On Thu, Feb 04, 2021 at 04:43:53PM -0500, Thara Gopinath wrote:
Crypto engine BAM dma does not support 0 length data. Return unsupported
if zero length messages are passed for transformation.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qc
On Thu, Feb 04, 2021 at 04:43:54PM -0500, Thara Gopinath wrote:
> + /*
> + * ECB and CBC algorithms require message lengths to be
> + * multiples of block size.
> + * TODO: The spec says AES CBC mode for certain versions
> + * of crypto engine can handle partial blocks as we
On Thu, Feb 04, 2021 at 04:43:53PM -0500, Thara Gopinath wrote:
> Crypto engine BAM dma does not support 0 length data. Return unsupported
> if zero length messages are passed for transformation.
>
> Signed-off-by: Thara Gopinath
> ---
> drivers/crypto/qce/skcipher.c | 5 +
> 1 file changed,
Return unsupported if any three keys are same for DES3 algorithms
since CE does not support this and the operation causes the engine to
hang.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/crypto/qce/sk
ECB transformations do not have an IV and hence set the ivsize to 0 for
ecb(aes).
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
index 28bea9584c33..
ECB/CBC encryption/decryption requires the data to be blocksize aligned.
Crypto engine hangs on non-block sized operations for these algorithms.
Return invalid data if data size is not blocksize aligned for these
algorithms.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 12 ++
The following are the conditions for requesting AES fallback cipher.
- AES-192
- AES-XTS request with len <= 512 byte (Allow messages of length
less than 512 bytes for all other AES encryption algorithms other
than AES XTS)
- AES-XTS request with len > Q
Crypto engine does not support key1 = key2 for AES XTS algorithm; the
operation hangs the engines. Return -EINVAL in case key1 and key2 are the
same.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff -
Crypto engine BAM dma does not support 0 length data. Return unsupported
if zero length messages are passed for transformation.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/
Crypto engine BAM dma does not support 0 length data. Return unsupported
if zero length messages are passed for transformation.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/
The following are the conditions for requesting AES fallback cipher.
- AES-192
- AES-XTS request with len <= 512 byte (Allow messages of length
less than 512 bytes for all other AES encryption algorithms other
than AES XTS)
- AES-XTS request with len > Q
ECB transformations do not have an IV and hence set the ivsize to 0 for
ecb(aes).
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/qce/skcipher.c b/drivers/crypto/qce/skcipher.c
index 28bea9584c33..
Return unsupported if any three keys are same for DES3 algorithms
since CE does not support this and the operation causes the engine to
hang.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/crypto/qce/sk
ECB/CBC encryption/decryption requires the data to be blocksize aligned.
Crypto engine hangs on non-block sized operations for these algorithms.
Return invalid data if data size is not blocksize aligned for these
algorithms.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 12 ++
Crypto engine does not support key1 = key2 for AES XTS algorithm; the
operation hangs the engines. Return -EINVAL in case key1 and key2 are the
same.
Signed-off-by: Thara Gopinath
---
drivers/crypto/qce/skcipher.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff -
On Wed 20 Jan 12:48 CST 2021, Thara Gopinath wrote:
> This patch contains the following fixes for the supported encryption
> algorithms in the Qualcomm crypto engine(CE)
> 1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
> does not support this and the operation causes the engin
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupported if any three keys are same f
for skcipher implementations,
by moving the FPU begin/end calls inside the skcipher walk processing
loop. Considering that skcipher walks operate on at most one page at a
time, doing so fully mitigates this issue.
This also permits the skcipher walk logic to use non-atomic kmalloc()
calls etc so we
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupprted if any three keys are same fo
This patch contains the following fixes for the supported encryption
algorithms in the Qualcomm crypto engine(CE)
1. Return unsupported if key1 = key2 for AES XTS algorithm since CE
does not support this and the operation causes the engine to hang.
2. Return unsupprted if any three keys are same fo
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
skcipher encrypt and decrypt routines from outside of task or softirq
context.
Signed-off-by: Ard Biesheuvel
---
crypto/skcipher.c | 10 ++
1
Add new skcipher algorithms for Kunpeng930 SEC:
OFB(AES), CFB(AES), CTR(AES),
OFB(SM4), CFB(SM4), CTR(SM4).
Signed-off-by: Wenkai Lin
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 88 +++---
drivers/crypto/hisilicon/sec2/sec_crypto.h | 2
kfree(edesc);
/*
* If no backlog flag, the completion of the request is done
@@ -1604,7 +1607,7 @@ static struct skcipher_edesc *skcipher_edesc_alloc(struct
skcipher_request *req,
dma_addr_t iv_dma = 0;
u8 *iv;
int ivsize = crypto_skcipher_ivsize(skciphe
Add new skcipher algorithms to Kunpeng930:
OFB(AES), CFB(AES), CTR(AES),
OFB(SM4), CFB(SM4), CTR(SM4).
Signed-off-by: Wenkai Lin
Signed-off-by: Longfang Liu
---
drivers/crypto/hisilicon/sec2/sec_crypto.c | 47 ++
drivers/crypto/hisilicon/sec2/sec_crypto.h | 2 ++
2
kfree(edesc);
/*
* If no backlog flag, the completion of the request is done
@@ -1604,7 +1607,7 @@ static struct skcipher_edesc *skcipher_edesc_alloc(struct
skcipher_request *req,
dma_addr_t iv_dma = 0;
u8 *iv;
int ivsize = crypto_skcipher_ivsize(skciphe
WireGuard and IPsec both typically operate on input blocks that are
~1420 bytes in size, given the default Ethernet MTU of 1500 bytes and
the overhead of the VPN metadata.
Many aead and sckipher implementations are optimized for power-of-2
block sizes, and whether they perform well when operating
WireGuard and IPsec both typically operate on input blocks that are
~1420 bytes in size, given the default Ethernet MTU of 1500 bytes and
the overhead of the VPN metadata.
Many aead and sckipher implementations are optimized for power-of-2
block sizes, and whether they perform well when operating
r when checking whether the
driver is the generic driver or not.
Fix this for the skcipher algorithm tests by getting the driver name
from the crypto_skcipher that actually got allocated.
Signed-off-by: Eric Biggers
---
crypto/testmgr.c | 36
1 file changed, 16 in
On 9/16/2020 12:50 AM, Richard Weinberger wrote:
> - Ursprüngliche Mail -
>> Von: "horia geanta"
How to use it with cryptsetup?
I'm asking because it is not clear to me why you are not implementing
a new kernel key type (KEYS subsystem)
to utilize tagged keys.
Many
t; they are and how to handle them using tag_object API.
>>>
>>> Add support, for tagged keys, to skcipher algorithms by
>>> adding new transformations, with _tk_ prefix to distinguish
>>> between plaintext and tagged keys.
>>>
>>> For job descrip
- Ursprüngliche Mail -
> Von: "horia geanta"
>>> How to use it with cryptsetup?
>>> I'm asking because it is not clear to me why you are not implementing
>>> a new kernel key type (KEYS subsystem)
>>> to utilize tagged keys.
>>> Many tools already support the keyctl userspace interface (cr
On Thu, Jul 16, 2020 at 4:12 PM Richard Weinberger
wrote:
>
> On Mon, Jul 13, 2020 at 12:09 AM Iuliana Prodan
> wrote:
> >
> > Tagged keys are keys that contain metadata indicating what
> > they are and how to handle them using tag_object API.
> >
> > Ad
On Mon, Aug 31, 2020 at 06:16:42PM +0300, Ard Biesheuvel wrote:
> RC4 hasn't aged very well, and is a poor fit for the skcipher API so it
> would be good if we could get rid of the ecb(arc4) drivers in the kernel
> at some point in the future. This prevents new users from creeping in
On Mon, Aug 31, 2020 at 06:16:49PM +0300, Ard Biesheuvel wrote:
>
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
This needs kernel.h too for the pr_warn_ratelimited. I'll add
it when I apply the series.
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au
local implementation, we can take the next step, and mark the ecb(arc4)
skcipher as obsolete, and only provide it if the socket API is enabled in
the first place, as well as provide the option to disable all algorithms
that have been marked as obsolete.
[0]
https://git.kernel.org/pub/scm/network/wir
RC4 hasn't aged very well, and is a poor fit for the skcipher API so it
would be good if we could get rid of the ecb(arc4) drivers in the kernel
at some point in the future. This prevents new users from creeping in, and
allows us to improve the skcipher API without having to care too much
On Mon, Aug 24, 2020 at 03:30:01PM +0200, Ard Biesheuvel wrote:
>
> +config CRYPTO_USER_ENABLE_OBSOLETE
> + bool "Enable obsolete cryptographic algorithms for userspace"
> + depends on CRYPTO_USER
That should be CRYPTO_USER_API which is the option for af_alg.
CRYPTO_USER is the configurati
On Mon, 24 Aug 2020 at 15:35, Herbert Xu wrote:
>
> On Mon, Aug 24, 2020 at 03:30:01PM +0200, Ard Biesheuvel wrote:
> >
> > +config CRYPTO_USER_ENABLE_OBSOLETE
> > + bool "Enable obsolete cryptographic algorithms for userspace"
> > + depends on CRYPTO_USER
>
> That should be CRYPTO_USER_AP
local implementation, we can take the next step, and mark the ecb(arc4)
skcipher as obsolete, and only provide it if the socket API is enabled in
the first place, as well as provide the option to disable all algorithms
that have been marked as obsolete.
[0]
https://git.kernel.org/pub/scm/network/wir
RC4 hasn't aged very well, and is a poor fit for the skcipher API so it
would be good if we could get rid of the ecb(arc4) drivers in the kernel
at some point in the future. This prevents new users from creeping in, and
allows us to improve the skcipher API without having to care too much
> What we could do instead is having a certain flag/behavior in skcipher
> where writes are omitted entirely, and cbcmac/cmac could opt into
> that. But imho, the best way to improve this is to have a new AES-NI
> asm helper (which I already implemented in my v2) that wraps the
> AES-NI
On Tue, 18 Aug 2020 at 10:25, Herbert Xu wrote:
>
> Many architectures provide an accelerated implementation of cbc(aes)
> skcipher that is far superior to using the standard cbc template
> over an accelerated aes cipher. As cmac uses the raw cipher, it
> was not able to b
On 2020-08-19 00:27, Herbert Xu wrote:
On Wed, Aug 19, 2020 at 08:15:50AM +1000, Herbert Xu wrote:
On Tue, Aug 18, 2020 at 07:17:35AM -0700, Ben Greear wrote:
Is there any easy way to use your work to make shash fast for aesni? I
basically just want it to perform as well as it used to with my
On Thu, Aug 20, 2020 at 03:09:55PM -0700, Ben Greear wrote:
>
> I have always assumed that I need aesni instructions to have any chance at
> this performing well,
> but there are certainly chips out there that don't have aesni, so possibly it
> is still worth improving
> if it is relatively easy
On 8/20/20 1:10 PM, Herbert Xu wrote:
On Thu, Aug 20, 2020 at 06:54:58AM -0700, Ben Greear wrote:
Here's a run on an: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
[ 259.397910] tcrypt: test 8 ( 1024 byte blocks, 1024 byte
On Thu, Aug 20, 2020 at 06:54:58AM -0700, Ben Greear wrote:
>
> Here's a run on an: Intel(R) Core(TM) i7-7700T CPU @ 2.90GHz
>
>testing speed of async cmac(aes-aesni) (cmac(aes-aesni))
>
> [ 259.397910] tcrypt: test 8 ( 1024 byte blocks, 1024 bytes per update, 1
> updates):
On 8/20/20 12:56 AM, Ard Biesheuvel wrote:
On Thu, 20 Aug 2020 at 09:54, Herbert Xu wrote:
On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
Or are you saying on Ben's machine cbc-aesni would have worse
performance vs. aes-generic?
Yes, given the pathological overhead of FP
On Thu, 20 Aug 2020 at 09:54, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
> >
> > > Or are you saying on Ben's machine cbc-aesni would have worse
> > > performance vs. aes-generic?
> > >
> >
> > Yes, given the pathological overhead of FPU preserve/restore
On Thu, Aug 20, 2020 at 09:48:02AM +0200, Ard Biesheuvel wrote:
>
> > Or are you saying on Ben's machine cbc-aesni would have worse
> > performance vs. aes-generic?
> >
>
> Yes, given the pathological overhead of FPU preserve/restore for every
> block of 16 bytes processed by the cbcmac wrapper.
given the pathological overhead of FPU preserve/restore for every
block of 16 bytes processed by the cbcmac wrapper.
> > The mac80211 CCMP code uses a synchronous ccm aead, which gets backed
> > by a skcipher+ahash combo by the ccm template. So a synchronous ahash
> > is fine fo
e performance.
Why does that matter? These are numbers for cbc-aesni which means
just a single preserve/restore for the whole request.
Or are you saying on Ben's machine cbc-aesni would have worse
performance vs. aes-generic?
> The mac80211 CCMP code uses a synchronous ccm aead, which g
;t had the
> > spare cycles to spend on this.
>
> I don't have an issue your patch per se. But please make it so that
> it has the async path like everything else. Also wireless uses shash
> so it can't use an ahash anyway even if it is sync.
>
The mac80211 CCMP code uses a synchronous ccm aead, which gets backed
by a skcipher+ahash combo by the ccm template. So a synchronous ahash
is fine for this particular case.
On Thu, Aug 20, 2020 at 09:19:16AM +0200, Ard Biesheuvel wrote:
>
> Actually, I'm not so sure that they will be so much worse. The
> expensive FPU preserve/restore occurs for every 16 bytes of data
> processed by the AES cipher, which I'd estimate to take ~10 cycles per
> byte for an unaccelerated
On Thu, 20 Aug 2020 at 09:06, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:04:26AM +0200, Ard Biesheuvel wrote:
> >
> > I don't disagree with that, especially given all the effort that went
> > into optimizing FPU preserve/restore on both arm64 and x86. But the
> > bottom line is that this is
On Thu, Aug 20, 2020 at 09:04:26AM +0200, Ard Biesheuvel wrote:
>
> I don't disagree with that, especially given all the effort that went
> into optimizing FPU preserve/restore on both arm64 and x86. But the
> bottom line is that this is what is causing the degradation in Ben's
> case, so we cannot
On Thu, 20 Aug 2020 at 09:01, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 08:58:15AM +0200, Ard Biesheuvel wrote:
> >
> > But if we look at the actual issue at hand, we might also look into
> > amortizing the FPU preserve/restore over multiple invocations of a
> > cipher. I proposed a patch a wh
On Thu, Aug 20, 2020 at 08:58:15AM +0200, Ard Biesheuvel wrote:
>
> But if we look at the actual issue at hand, we might also look into
> amortizing the FPU preserve/restore over multiple invocations of a
> cipher. I proposed a patch a while ago that makes cipher an internal
> crypto API abstractio
On Wed, 19 Aug 2020 at 00:39, Ben Greear wrote:
>
> On 8/18/20 3:33 PM, Herbert Xu wrote:
> > On Tue, Aug 18, 2020 at 03:31:10PM -0700, Ben Greear wrote:
> >>
> >> I don't think it has been discussed recently, but mac80211 is already
> >> a complicated beast, so if this added any significant compl
On 8/18/20 3:33 PM, Herbert Xu wrote:
On Tue, Aug 18, 2020 at 03:31:10PM -0700, Ben Greear wrote:
I don't think it has been discussed recently, but mac80211 is already
a complicated beast, so if this added any significant complexity
it might not be worth it.
Any bulk data path should be using
On Tue, Aug 18, 2020 at 03:31:10PM -0700, Ben Greear wrote:
>
> I don't think it has been discussed recently, but mac80211 is already
> a complicated beast, so if this added any significant complexity
> it might not be worth it.
Any bulk data path should be using the async interface, otherwise
per
On 8/18/20 3:27 PM, Herbert Xu wrote:
On Wed, Aug 19, 2020 at 08:15:50AM +1000, Herbert Xu wrote:
On Tue, Aug 18, 2020 at 07:17:35AM -0700, Ben Greear wrote:
Is there any easy way to use your work to make shash fast for aesni? I
basically just want it to perform as well as it used to with my
On Wed, Aug 19, 2020 at 08:15:50AM +1000, Herbert Xu wrote:
> On Tue, Aug 18, 2020 at 07:17:35AM -0700, Ben Greear wrote:
> >
> > Is there any easy way to use your work to make shash fast for aesni? I
> > basically just want it to perform as well as it used to with my patch.
>
> Yes. We could ad
On Tue, Aug 18, 2020 at 07:17:35AM -0700, Ben Greear wrote:
>
> Is there any easy way to use your work to make shash fast for aesni? I
> basically just want it to perform as well as it used to with my patch.
Yes. We could add a sync version of aesni that simply falls back
to aes-generic when sim
On 8/18/20 7:05 AM, Herbert Xu wrote:
On Tue, Aug 18, 2020 at 06:56:12AM -0700, Ben Greear wrote:
Herbert, thanks for working on this. If I apply the patches you posted,
that is expected to provide wifi aes decryption speedup similar to what
the original patch I sent does? Or, are additional
On Tue, Aug 18, 2020 at 06:56:12AM -0700, Ben Greear wrote:
>
> Herbert, thanks for working on this. If I apply the patches you posted,
> that is expected to provide wifi aes decryption speedup similar to what
> the original patch I sent does? Or, are additional patches needed?
It depends on whe
On 8/18/20 6:51 AM, Herbert Xu wrote:
On Tue, Aug 18, 2020 at 10:31:39AM +0200, Ard Biesheuvel wrote:
What do you mean? You cannot implement cbcmac using a cbc skcipher
unless you provide a scratch buffer of arbitrary size as the
destination, in order to capture the skcipher output IV as the
On Tue, Aug 18, 2020 at 10:31:39AM +0200, Ard Biesheuvel wrote:
>
> What do you mean? You cannot implement cbcmac using a cbc skcipher
> unless you provide a scratch buffer of arbitrary size as the
> destination, in order to capture the skcipher output IV as the MAC.
Please have a loo
| 39 +++
> > arch/x86/crypto/aesni-intel_glue.c | 42 +---
> > arch/x86/crypto/aesni-intel_mac.c | 257 ++++
> > 4 files changed, 306 insertions(+), 34 deletions(-)
>
> We should just use the accelerated cbc skcipher.
>
What do you mean? You cannot im
Many architectures provide an accelerated implementation of cbc(aes)
skcipher that is far superior to using the standard cbc template
over an accelerated aes cipher. As cmac uses the raw cipher, it
was not able to benefit from the accelerated cbc(aes) skcpipher.
This patch changes cmac to use an
This patch adds helpers for using sync skciphers as spawns from
crypto instances.
In doing so it also changes the error returned when an algorithm
exceeds the maximum sync skcipher request size from EINVAL to E2BIG
as the former is used for way too many things.
Also the CRYPTO_ALG_ASYNC bit is
4 files changed, 306 insertions(+), 34 deletions(-)
We should just use the accelerated cbc skcipher.
Cheers,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
; > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> > > > >
> > > > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
> > > > >
> > > > > On Thu, Jul 02, 2020 at 12:19:44PM +0200, Ard Biesheuvel wrote:
> > >
On Tue, Jul 28, 2020 at 10:19:21AM -0700, Eric Biggers wrote:
>
> Can you elaborate on the use case for supporting chaining on algorithms that
> don't currently support it?
OK I will describe the algif issue in more detail and also add
a mention of sunrpc. In fact I might try to convert sunrpc to
On Tue, Jul 28, 2020 at 10:10:59AM -0700, Eric Biggers wrote:
>
> Does this really work? Some users allocate memory themselves without using
> *_request_alloc().
Yes good point. I will instead add a second request flag used to
indicate that we should retain the internal state.
Thanks,
--
Email
On Tue, Jul 28, 2020 at 08:46:42PM +0300, Ard Biesheuvel wrote:
>
> > Yes we could add a flag for it. However, for the two users that
> > I'm looking at right now (algif_skcipher and sunrpc) this is not
> > required. For algif_skcipher it'll simply fall back to the current
> > behaviour if chaini
On Tue, 28 Jul 2020 at 20:30, Herbert Xu wrote:
>
> On Tue, Jul 28, 2020 at 08:26:38PM +0300, Ard Biesheuvel wrote:
> >
> > So how does one allocate a tfm that supports chaining if their use
> > case requires it? Having different implementations of the same algo
> > where one does support it while
On Tue, Jul 28, 2020 at 08:26:38PM +0300, Ard Biesheuvel wrote:
>
> So how does one allocate a tfm that supports chaining if their use
> case requires it? Having different implementations of the same algo
> where one does support it while the other one doesn't means we will
> need some flag to requ
On Tue, 28 Jul 2020 at 20:22, Herbert Xu wrote:
>
> On Tue, Jul 28, 2020 at 10:15:12AM -0700, Eric Biggers wrote:
> >
> > Shouldn't chaining be disabled by default? This is inviting bugs where
> > drivers
> > don't implement chaining, but leave final_chunksize unset (0) which
> > apparently
> >
On Tue, Jul 28, 2020 at 10:15:12AM -0700, Eric Biggers wrote:
>
> Shouldn't chaining be disabled by default? This is inviting bugs where
> drivers
> don't implement chaining, but leave final_chunksize unset (0) which apparently
> indicates that chaining is supported.
I've gone through everything
On Tue, Jul 28, 2020 at 05:17:46PM +1000, Herbert Xu wrote:
> This patch-set adds support to the Crypto API and algif_skcipher
> for algorithms that cannot be chained, as well as ones that can
> be chained if you withhold a certain number of blocks at the end.
>
> The vast majority of algorithms c
On Tue, Jul 28, 2020 at 05:18:39PM +1000, Herbert Xu wrote:
> Crypto skcipher algorithms in general allow chaining to break
> large operations into smaller ones based on multiples of the chunk
> size. However, some algorithms don't support chaining while others
> (such as
On Tue, Jul 28, 2020 at 05:18:55PM +1000, Herbert Xu wrote:
> This patch initialises skcipher requests to zero. This allows
> algorithms to distinguish between the first operation versus
> subsequent ones.
>
> Signed-off-by: Herbert Xu
> ---
>
> include/
As it is the reqsize field only exists on the tfm object which means
that in order to set it you must provide an init function for the
tfm, even if the size is actually static.
This patch adds a reqsize field to the skcipher alg object which
allows it to be set without having an init function
1 - 100 of 1017 matches
Mail list logo
