Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7
eless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1
lds"
Cc: Chuck Lever
Cc: Eric Biggers
Cc: Arnd Bergmann
Cc: linux-crypto@vger.kernel.org
Cc: net...@vger.kernel.org
Cc: de...@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library
nly
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/l
On Fri, 28 Aug 2020 at 12:24, Giovanni Cabiddu
wrote:
>
> On Sat, Aug 22, 2020 at 02:04:10PM +0100, Ard Biesheuvel wrote:
> > On Sat, 22 Aug 2020 at 09:29, Giovanni Cabiddu
> > wrote:
> > >
> > > From: Dominik Przychodni
> > >
> > > Inclu
On Thu, 27 Aug 2020 at 11:20, Arnd Bergmann wrote:
>
> On Thu, Aug 27, 2020 at 10:42 AM Ard Biesheuvel wrote:
> >
> > In that case, I suppose we should simply disable instrumentation for
> > chacha_permute()? It is a straight-forward arithmetic transformation
> > o
On Thu, 27 Aug 2020 at 10:33, Arnd Bergmann wrote:
>
> On Thu, Aug 27, 2020 at 10:10 AM Ard Biesheuvel wrote:
> > On Thu, 27 Aug 2020 at 10:06, Herbert Xu
> > wrote:
> > >
> > > On Thu, Aug 27, 2020 at 11:52:50AM +0800, kernel test robot wrote:
> > &
(+ Arnd)
On Thu, 27 Aug 2020 at 10:06, Herbert Xu wrote:
>
> On Thu, Aug 27, 2020 at 11:52:50AM +0800, kernel test robot wrote:
> >
> > First bad commit (maybe != root cause):
> >
> > tree: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> > master
> > head: 15bc20c6af4cee
ed fix the original iwd 1.8 + WPA
> Enterprise issue.
>
> Thank you!
>
> Caleb Jorden
>
Thanks for confirming.
>
> From: Herbert Xu
> Sent: Thursday, August 27, 2020 3:49 AM
> To: Ard Biesheuvel
> Cc: Denis Kenzior; Andrew
On Thu, 27 Aug 2020 at 09:15, Herbert Xu wrote:
>
> On Thu, Aug 27, 2020 at 08:40:01AM +0200, Ard Biesheuvel wrote:
> >
> > It is part of iwd - just build that and run 'make check'
> >
> > With your patch applied, the occurrence of sendmsg() in
> >
On Thu, 27 Aug 2020 at 00:19, Herbert Xu wrote:
>
> On Wed, Aug 26, 2020 at 05:42:27PM +0200, Ard Biesheuvel wrote:
> >
> > I still get a failure in aes_siv_encrypt(), which does not occur with
> > the kernel side fix applied.
>
> Where is this test from? I can
On Wed, 26 Aug 2020 at 17:33, Denis Kenzior wrote:
>
> Hi Herbert,
>
> On 8/26/20 9:19 AM, Herbert Xu wrote:
> > On Wed, Aug 26, 2020 at 08:57:17AM -0500, Denis Kenzior wrote:
> >>
> >> I'm just waking up now, so I might seem dense, but for my education, can
> >> you
> >> tell me why we need to s
: f3c802a1f300 ("crypto: algif_aead - Only wake up when...")
> Cc:
> Signed-off-by: Herbert Xu
>
Applied this onto v5.4.60, and it makes the iwd selftests pass again
Acked-by: Ard Biesheuvel
Tested-by: Ard Biesheuvel
> diff --git a/crypto/af_alg.c b/crypto/af_alg.c
&
On Wed, 26 Aug 2020 at 13:50, Herbert Xu wrote:
>
> On Wed, Aug 26, 2020 at 12:40:14PM +0200, Ard Biesheuvel wrote:
> >
> > It would be helpful if someone could explain for the non-mac80211
> > enlightened readers how iwd's EAP-PEAPv0 + MSCHAPv2 support relies
On Tue, 18 Aug 2020 at 10:25, Herbert Xu wrote:
>
> This patch removes AHASH_REQUEST_ON_STACK which is unused.
>
> Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
and given that any new uses that creep in will trigger -Wvla warnings,
I suggest this is broken out from the serie
On Wed, 26 Aug 2020 at 08:18, Paul Menzel wrote:
>
>
> Dear Caleb,
>
>
> Thank you for the report. Linux has a no regression policy, so the
> correct forum to report this to is the Linux kernel folks. I am adding
> the crypto and stable folks to the receiver list.
>
> Am 26.08.20 um 07:51 schrieb
On Tue, 25 Aug 2020 at 03:41, Herbert Xu wrote:
>
> This patch changes a couple u128's to be128 which is the correct
> type to use and fixes a few sparse warnings.
>
> Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
>
> diff --git a/arch/arm64/crypto/ghash-ce-glu
uld it be static?
> ../arch/arm64/crypto/sha2-ce-glue.c:40:11: warning: symbol
> 'sha256_ce_offsetof_finalize' was not declared. Should it be static?
>
> Signed-off-by: Herbert Xu
Acked-by: Ard Biesheuvel
>
> diff --git a/arch/arm64/crypto/sha1-ce-glue.c
> b/arch/arm64/crypto/s
t-function-declaration]
>
> Include to fix such warnings
>
> Reported-by: Olof's autobuilder
> Signed-off-by: Fabio Estevam
Thanks for the fix - I just hit this as well.
Acked-by: Ard Biesheuvel
> ---
> arch/arm/crypto/curve25519-glue.c | 1 +
> 1 file changed, 1 insertion
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
Drop some bogus Kconfig selects that are not entirely accurate, and
unnecessary to begin with, since the same Kconfig options also select
LIB80211 features that already imply the selected functionality (AES
for CCMP, ARC4 and ECB for TKIP)
Signed-off-by: Ard Biesheuvel
---
drivers/net/wireless
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"
> > + d
eless/iwd.git/commit/?id=1db8a85a60c64523
[1] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=53482ce421b727c2
[2] https://git.kernel.org/pub/scm/libs/ell/ell.git/commit/?id=7f6a137809d42f6b
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 10 ++
crypto/arc4.c | 10
nly
adversely affect interoperability with Windows NT/2000 systems that have
not received any updates since 2008 (but are connected to a network
nonetheless)
[0] https://tools.ietf.org/html/rfc4757
[1] https://tools.ietf.org/html/rfc8429
Signed-off-by: Ard Biesheuvel
Acked-by: J. Bruce Fields
---
include/l
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/n2_core.c | 46
1 file changed, 46 deletions(-)
diff --git a/drivers/crypto/n2_core.c b/drivers/crypto/n2_core.c
index d8aec5153b21..8c8e17d5fb20 100644
--- a/drivers/crypto/n2_core.c
+++ b/drivers/crypto/n2_core.c
@@ -662,7
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
Acked-by: Greg Kroah-Hartman
---
drivers/staging/rtl8192u/Kconfig | 1
driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library interface
SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
crypto: n2 - remove ecb(arc4) support
crypto: bcm-iproc - remove ecb(arc4) suppo
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 benefit from the accelera
On Sat, 22 Aug 2020 at 09:29, Giovanni Cabiddu
wrote:
>
> From: Dominik Przychodni
>
> Include an additional check on the cipher length to prevent undefined
> behaviour from occurring upon submitting requests which are not a
> multiple of AES_BLOCK_SIZE.
>
> Fixes: d370cec32194 ("crypto: qat - In
On Fri, 21 Aug 2020 at 05:55, Herbert Xu wrote:
>
> On Mon, Aug 17, 2020 at 03:03:11PM +0300, Felipe Balbi wrote:
> >
> > Hi,
> >
> > I'm not sure if there's already a patch for this, but I notices arm64
> > allmodconfig fails to build with GCC 10.2 as shown below:
> >
> > crypto/aegis128-neon-inn
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,
On Thu, 20 Aug 2020 at 09:44, Herbert Xu wrote:
>
> On Thu, Aug 20, 2020 at 09:33:21AM +0200, Ard Biesheuvel wrote:
> >
> > > On my machine the performance difference on a 1472-byte request
> > > between SIMD and generic is 2161 vs. 7558 (cycles).
> >
> >
On Thu, 20 Aug 2020 at 09:29, Herbert Xu wrote:
>
> 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
> >
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
&g
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
> >
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 Tue, 18 Aug 2020 at 10:24, Herbert Xu wrote:
>
> On Sun, Aug 02, 2020 at 12:06:16PM +0300, Ard Biesheuvel wrote:
> > Ben reports that CCM using AES-NI instructions performs pathologically
> > poorly, which is due to the overhead of preserving/restoring the SIMD
> >
On Tue, 4 Aug 2020 at 21:45, Ben Greear wrote:
>
> On 8/4/20 6:08 AM, Ard Biesheuvel wrote:
> > On Tue, 4 Aug 2020 at 15:01, Ben Greear wrote:
> >>
> >> On 8/4/20 5:55 AM, Ard Biesheuvel wrote:
> >>> On Mon, 3 Aug 2020 at 21:11, Ben Greear wrote:
>
On Sat, 25 Jul 2020 at 10:06, Ard Biesheuvel wrote:
>
> On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote:
> >
> > On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
> > >
> > > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> > > >
> >
On Tue, 4 Aug 2020 at 15:01, Ben Greear wrote:
>
> On 8/4/20 5:55 AM, Ard Biesheuvel wrote:
> > On Mon, 3 Aug 2020 at 21:11, Ben Greear wrote:
> >>
> >> Hello,
> >>
> >> This helps a bit...now download sw-crypt performance is about 150Mbps,
&g
bcmac(aes), which takes
care to only preserve/restore the SIMD state after processing the
whole input, and convert it into an ahash implementation, which gives
us more control over the way FPU preserve/restore can be amortized over
the entire request.
Cc: Ben Greear
Signed-off-by: Ard Biesh
On Mon, 3 Aug 2020 at 21:11, Ben Greear wrote:
>
> Hello,
>
> This helps a bit...now download sw-crypt performance is about 150Mbps,
> but still not as good as with my patch on 5.4 kernel, and fpu is still
> high in perf top:
>
> 13.89% libc-2.29.so [.] __memset_sse2_unaligned_erms
>
bcmac(aes), which takes
care to only preserve/restore the SIMD state after processing the
whole input. Since cmac(aes) and xcbc(aes) can reuse most of the code,
let's expose those as well.
Cc: Ben Greear
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/Makefile | 2 +-
arch/
On Fri, 31 Jul 2020 at 01:57, Ben Greear wrote:
>
> On 7/29/20 1:06 PM, Ard Biesheuvel wrote:
> > On Wed, 29 Jul 2020 at 22:29, Ben Greear wrote:
> >>
> >> On 7/29/20 12:09 PM, Ard Biesheuvel wrote:
> >>> On Wed, 29 Jul 2020 at 15:27, Ben Greear wro
On Wed, 29 Jul 2020 at 22:29, Ben Greear wrote:
>
> On 7/29/20 12:09 PM, Ard Biesheuvel wrote:
> > On Wed, 29 Jul 2020 at 15:27, Ben Greear wrote:
> >>
> >> On 7/28/20 11:06 PM, Ard Biesheuvel wrote:
> >>> On Wed, 29 Jul 2020 at 01:03, Ben Greear wr
On Wed, 29 Jul 2020 at 15:27, Ben Greear wrote:
>
> On 7/28/20 11:06 PM, Ard Biesheuvel wrote:
> > On Wed, 29 Jul 2020 at 01:03, Ben Greear wrote:
> >>
> >> Hello,
> >>
> >> As part of my wifi test tool, I need to do decrypt AES on the CPU, and
On Tue, 28 Jul 2020 at 10:19, Herbert Xu wrote:
>
> As it stands chacha cannot do chaining. That is, it has to handle
> each request as a whole. This patch adds support for chaining when
> the CRYPTO_TFM_REQ_MORE flag is set.
>
> Signed-off-by: Herbert Xu
Only state[12] needs to be preserved,
On Wed, 29 Jul 2020 at 01:03, Ben Greear wrote:
>
> Hello,
>
> As part of my wifi test tool, I need to do decrypt AES on the CPU, and the
> only way this
> performs well is to use aesni. I've been using a patch for years that does
> this, but
> recently somewhere between 5.4 and 5.7, the API I'
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
>
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, 28 Jul 2020 at 15:03, Herbert Xu wrote:
>
> On Tue, Jul 28, 2020 at 02:59:24PM +0300, Ard Biesheuvel wrote:
> >
> > How is it malformed? Between 16 and 31 bytes of input is perfectly
> > valid for cts(cbc(aes)), and splitting it up after the first chunk
> > s
On Tue, 28 Jul 2020 at 14:53, Herbert Xu wrote:
>
> On Tue, Jul 28, 2020 at 02:05:58PM +0300, Ard Biesheuvel wrote:
> >
> > But isn't the final chunksize a function of cryptlen? What happens if
> > i try to use cts(cbc(aes)) to encrypt 16 bytes with the MORE flag, an
On Tue, 28 Jul 2020 at 10:18, Herbert Xu wrote:
>
> As it stands cts cannot do chaining. That is, it always performs
> the cipher-text stealing at the end of a request. This patch adds
> support for chaining when the CRYPTO_TM_REQ_MORE flag is set.
>
> It also sets final_chunksize so that data c
On Sat, 18 Jul 2020 at 11:18, Ard Biesheuvel wrote:
>
> On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> > >
> > > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> > > >
>
bf8163 ("crypto: xts - add support for ciphertext stealing")
Reported-by: Colin Ian King
Signed-off-by: Ard Biesheuvel
---
crypto/xts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/xts.c b/crypto/xts.c
index 3c3ed02c7663..ad45b009774b 100644
--- a/crypto/xts.
On Sun, 19 Jul 2020 at 19:29, Alexander A. Klimov
wrote:
>
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
>
> Deterministic algorithm:
> For each file:
> If not .svg:
> For each line:
> If doesn't contain
On Sat, 18 Jul 2020 at 12:43, Sven Auhagen wrote:
>
> Balance the irqs of the inside secure driver over all
> available cpus.
> Currently all interrupts are handled by the first CPU.
>
> From my testing with IPSec AES-GCM 256
> on my MCbin with 4 Cores I get a 50% speed increase:
>
> Before the pa
On Fri, 3 Jul 2020 at 02:04, Ard Biesheuvel wrote:
>
> On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
> >
> > On Thu, 2 Jul 2020 at 19:50, Eric Biggers wrote:
> > >
> > > [+linux-wireless, Marcel Holtmann, and Denis Kenzior]
> > >
> &
On Fri, 17 Jul 2020 at 08:21, Herbert Xu wrote:
>
> On Thu, Jul 16, 2020 at 06:56:30PM +0300, Ard Biesheuvel wrote:
> > On Thu, 16 Jul 2020 at 18:29, Colin King wrote:
> > >
> > > From: Colin Ian King
> > >
> > > There is a memcpy that perfor
On Thu, 16 Jul 2020 at 18:29, Colin King wrote:
>
> From: Colin Ian King
>
> There is a memcpy that performs a potential overlapped memory copy
> from source b to destination b + 1. Fix this by using the safer
> memmove instead.
>
> Addresses-Coverity: ("Overlapping buffer in memory copy")
> Fix
On Thu, 16 Jul 2020 at 17:56, Marcelo Henrique Cerri
wrote:
>
> On Thu, Jul 16, 2020 at 05:37:32PM +0300, Ard Biesheuvel wrote:
> > On Thu, 16 Jul 2020 at 17:23, Marcelo Henrique Cerri
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 04:53:24PM +0300, Ard Bies
On Thu, 16 Jul 2020 at 17:23, Marcelo Henrique Cerri
wrote:
>
> On Thu, Jul 16, 2020 at 04:53:24PM +0300, Ard Biesheuvel wrote:
> > On Thu, 16 Jul 2020 at 16:41, Marcelo Henrique Cerri
> > wrote:
> > >
> > > On Thu, Jul 16, 2020 at 04:09:39PM +0300, Ard Bies
On Thu, 16 Jul 2020 at 16:41, Marcelo Henrique Cerri
wrote:
>
> On Thu, Jul 16, 2020 at 04:09:39PM +0300, Ard Biesheuvel wrote:
> > On Thu, 16 Jul 2020 at 15:50, Marcelo Henrique Cerri
> > wrote:
> > >
> > > No. The code is really based on Gnu MP. I used the
y;
> wsize = VARIATION_NEG (abs_usize + cy);
> }
> else
> {
> /* The signs are different. Need exact comparison to determine
> which operand to subtract from which. */
> if (abs_usize == 1 && up[0] < vval)
> {
>
On Thu, 16 Jul 2020 at 10:30, Herbert Xu wrote:
>
> On Sun, Jul 12, 2020 at 06:39:54PM +0200, Stephan Müller wrote:
> >
> > diff --git a/lib/mpi/mpi-sub-ui.c b/lib/mpi/mpi-sub-ui.c
> > new file mode 100644
> > index ..fa6b085bac36
> > --- /dev/null
> > +++ b/lib/mpi/mpi-sub-ui.c
> > @@
On Fri, 10 Jul 2020 at 13:16, Stephan Müller wrote:
>
> Add mpi_sub_ui() based on Gnu PG mpz_sub_ui() from mpz/aors_ui.h
> adapting the code to the kernel's structures and coding style and also
> removing the defines used to produce mpz_sub_ui() and mpz_add_ui()
> from the same code.
>
Isn't GnuP
On Thu, 9 Jul 2020 at 11:53, Horia Geantă wrote:
>
> On 7/9/2020 3:47 AM, Herbert Xu wrote:
> > On Wed, Jul 08, 2020 at 07:24:08PM +0300, Horia Geantă wrote:
> >>
> >> I think the commit message should be updated to reflect this logic:
> >> indeed, caam's implementation of ecb(arc4) is broken,
> >
On Thu, 9 Jul 2020 at 11:22, Herbert Xu wrote:
>
> On Mon, Jun 29, 2020 at 09:39:25AM +0200, Ard Biesheuvel wrote:
> > Of the two versions of GHASH that the ARM driver implements, only one
> > performs aggregation, and so the other one has no use for the powers
> > of
On Wed, 8 Jul 2020 at 16:35, Van Leeuwen, Pascal wrote:
>
> Hi Ard,
>
> Thanks for responding!
>
> > > For the situation where this problem is occuring, the actual buffers are
> > > stored inside
> > > the ahash_req structure. So my question is: is there any reason why this
> > > structure may
>
On Wed, 8 Jul 2020 at 11:56, Van Leeuwen, Pascal wrote:
>
> Hi,
>
> I have a question on behalf of a customer of ours trying to use the
> inside-secure crypto
> API driver. They are experiencing issues with result data not arriving in the
> result buffer.
> This seems to have something to do wit
ff-by: Ard Biesheuvel
---
arch/x86/crypto/chacha-ssse3-x86_64.S | 16
arch/x86/crypto/chacha_glue.c | 17 ++---
include/crypto/chacha.h | 4
3 files changed, 10 insertions(+), 27 deletions(-)
diff --git a/arch/x86/crypto/chacha-ssse3-x86_64
On Wed, 8 Jul 2020 at 08:46, Ard Biesheuvel wrote:
>
> On Wed, 8 Jul 2020 at 05:44, Herbert Xu wrote:
> >
> > On Tue, Jul 07, 2020 at 07:31:08PM -0700, Eric Biggers wrote:
> > >
> > > Hmm, __chacha20poly1305_encrypt() already uses:
> > &
vert some users to use it.
>
> Eric Biggers (4):
> crypto: lib/sha256 - add sha256() function
> efi: use sha256() instead of open coding
> mptcp: use sha256() instead of open coding
> ASoC: cros_ec_codec: use sha256() instead of open coding
>
For the series,
Reviewed-by:
On Wed, 8 Jul 2020 at 05:44, Herbert Xu wrote:
>
> On Tue, Jul 07, 2020 at 07:31:08PM -0700, Eric Biggers wrote:
> >
> > Hmm, __chacha20poly1305_encrypt() already uses:
> >
> > memzero_explicit(chacha_state, CHACHA_STATE_WORDS * sizeof(u32));
> >
> > That's equivalent to CHACHA_BLOCK_SIZE no
outer request.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Horia Geantă
---
drivers/crypto/sahara.c | 96 +---
1 file changed, 45 insertions(+), 51 deletions(-)
diff --git a/drivers/crypto/sahara.c b/drivers/crypto/sahara.c
index 466e30bd529c..0c8cb23ae708 100644
--- a/drivers/c
outer request.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/chelsio/chcr_algo.c | 57
drivers/crypto/chelsio/chcr_crypto.h | 3 +-
2 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/drivers/crypto/chelsio/chcr_algo.c
b/drivers/crypto/chelsio/chcr_algo.c
instead.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/Kconfig| 3 +-
drivers/crypto/mediatek/mtk-aes.c | 63 +++-
2 files changed, 9 insertions(+), 57 deletions(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index 7bc58bf99703..585ad584e421 100644
outer request.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Horia Geantă
---
drivers/crypto/mxs-dcp.c | 33 ++--
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/mxs-dcp.c b/drivers/crypto/mxs-dcp.c
index d84530293036..909a7eb748e3 100644
--- a/dr
o the outer request.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Jamie Iles
---
drivers/crypto/picoxcell_crypto.c | 38 +++-
1 file changed, 22 insertions(+), 16 deletions(-)
diff --git a/drivers/crypto/picoxcell_crypto.c
b/drivers/crypto/picoxcell_crypto.c
index 7384e91
o the outer request.
While at it, remove the pointless memset() from qce_skcipher_init(), and
remove the call to it qce_skcipher_init_fallback().
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/qce/cipher.h | 3 +-
drivers/crypto/qce/skcipher.c | 42 ++--
2 files change
o the outer request.
Signed-off-by: Ard Biesheuvel
Acked-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ce/sun8i-ce-cipher.c | 41 ++--
drivers/crypto/allwinner/sun8i-ce/sun8i-ce.h| 8 ++--
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/c
o the outer request.
Signed-off-by: Ard Biesheuvel
Acked-by: Corentin Labbe
---
drivers/crypto/allwinner/sun8i-ss/sun8i-ss-cipher.c | 39 ++--
drivers/crypto/allwinner/sun8i-ss/sun8i-ss.h| 26 +++--
2 files changed, 34 insertions(+), 31 deletions(-)
diff --git a/dr
igned-off-by: Ard Biesheuvel
---
drivers/crypto/ccp/ccp-crypto-aes-xts.c | 33 ++--
drivers/crypto/ccp/ccp-crypto.h | 4 ++-
2 files changed, 19 insertions(+), 18 deletions(-)
diff --git a/drivers/crypto/ccp/ccp-crypto-aes-xts.c
b/drivers/crypto/ccp/ccp-crypto-aes-xts.c
pull in a huge chunk of the crypto stack as a builtin as well, which is
undesirable, so let's make the amlogic GXL driver default to 'm' instead.
Signed-off-by: Ard Biesheuvel
Tested-by: Corentin Labbe
---
drivers/crypto/amlogic/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 de
outer request.
Signed-off-by: Ard Biesheuvel
Tested-by: Corentin Labbe
---
drivers/crypto/allwinner/sun4i-ss/sun4i-ss-cipher.c | 46 ++--
drivers/crypto/allwinner/sun4i-ss/sun4i-ss.h| 3 +-
2 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/drivers/c
nfradead.org
Cc: linux-o...@vger.kernel.org
Cc: linux-amlo...@lists.infradead.org
Ard Biesheuvel (13):
crypto: amlogic-gxl - default to build as module
crypto: amlogic-gxl - permit async skcipher as fallback
crypto: omap-aes - permit asynchronous skcipher as fallback
crypto: sun4i - perm
o the outer request.
Signed-off-by: Ard Biesheuvel
Tested-by: Corentin Labbe
---
drivers/crypto/amlogic/amlogic-gxl-cipher.c | 27 ++--
drivers/crypto/amlogic/amlogic-gxl.h| 3 ++-
2 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/drivers/crypto/amlogic/am
given
to the outer request.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/omap-aes.c | 35 ++--
drivers/crypto/omap-aes.h | 3 +-
2 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index b5aff20c5900..25154b7
On Sun, 5 Jul 2020 at 22:11, Horia Geantă wrote:
>
> On 7/2/2020 7:36 AM, Herbert Xu wrote:
> > The arc4 algorithm requires storing state in the request context
> > in order to allow more than one encrypt/decrypt operation. As this
> > driver does not seem to do that, it means that using it for m
On Thu, 2 Jul 2020 at 20:21, Ard Biesheuvel wrote:
>
> 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:
> > > Remove t
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:
> > Remove the generic ecb(arc4) skcipher, which is slightly cumbersome from
> > a maintenance pe
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192e/Kconfig | 4 +-
drivers/staging/rtl8192e
.@driverdev.osuosl.org
Cc: linux-...@vger.kernel.org
Ard Biesheuvel (7):
staging/rtl8192e: switch to RC4 library interface
staging/rtl8192u: switch to RC4 library interface
SUNRPC: remove RC4-HMAC-MD5 support from KerberosV
crypto: remove ARC4 support from the skcipher API
crypto: n2 -
Signed-off-by: Ard Biesheuvel
---
crypto/tcrypt.c | 21 +--
crypto/testmgr.c | 7 ---
crypto/testmgr.h | 62
3 files changed, 1 insertion(+), 89 deletions(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index ba0b7702f2e9..72828c4acd3a 100644
--- a/crypto/tcrypt.c
Switch to the ARC4 library interface, to remove the pointless
dependency on the skcipher API, from which we will hopefully be
able to drop ecb(arc4) skcipher support.
Signed-off-by: Ard Biesheuvel
---
drivers/staging/rtl8192u/Kconfig | 1 +
drivers/staging/rtl8192u
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/bcm/cipher.c | 96 +---
drivers/crypto/bcm/cipher.h | 1 -
drivers/crypto/bcm/spu.c| 23 +
drivers/crypto/bcm/spu.h| 1 -
drivers/crypto/bcm/spu2.c | 12 +--
drivers/crypto/bcm/spu2.h | 1 -
6 files changed, 6
we have in the tree, we can safely drop this code now
it no longer has any users.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12
crypto/Makefile | 1 -
crypto/arc4.c| 76
401 - 500 of 2556 matches
Mail list logo
