[+Steffen, who is the maintainer of pcrypt]
On Fri, Aug 16, 2019 at 07:02:34PM -0700, Jakub Kicinski wrote:
> On Thu, 15 Aug 2019 11:06:00 -0700, syzbot wrote:
> > syzbot has bisected this bug to:
> >
> > commit 130b392c6cd6b2aed1b7eb32253d4920babb4891
> > Author: Dave Watson
> > Date: Wed Jan
On Fri, Aug 16, 2019 at 11:16:09PM +0200, Hans de Goede wrote:
> Use get_unaligned_be32 in the lib/crypto/sha256.c sha256_transform()
> implementation so that it can be used with unaligned buffers too,
> making it more generic.
>
> And use memzero_explicit for better clearing of sensitive data.
>
On Fri, Aug 16, 2019 at 10:13:18PM -0700, Eric Biggers wrote:
> On Fri, Aug 16, 2019 at 11:16:11PM +0200, Hans de Goede wrote:
> > Drop the duplicate sha256_transform function from crypto/sha256_generic.c
> > and use the implementation from lib/crypto/sha256.c instead.
> > "diff -u lib/crypto/sha25
On Fri, Aug 16, 2019 at 11:16:08PM +0200, Hans de Goede wrote:
> diff --git a/include/linux/sha256.h b/include/crypto/sha256.h
> similarity index 100%
> rename from include/linux/sha256.h
> rename to include/crypto/sha256.h
already has the declarations for both SHA-1 and SHA-2, including
SHA-256.
On Fri, Aug 16, 2019 at 11:16:11PM +0200, Hans de Goede wrote:
> Drop the duplicate sha256_transform function from crypto/sha256_generic.c
> and use the implementation from lib/crypto/sha256.c instead.
> "diff -u lib/crypto/sha256.c sha256_generic.c"
> shows that both implementations are identical.
On Thu, 15 Aug 2019 11:06:00 -0700, syzbot wrote:
> syzbot has bisected this bug to:
>
> commit 130b392c6cd6b2aed1b7eb32253d4920babb4891
> Author: Dave Watson
> Date: Wed Jan 30 21:58:31 2019 +
>
> net: tls: Add tls 1.3 support
>
> bisection log: https://syzkaller.appspot.com/x/bise
Use get_unaligned_be32 in the lib/crypto/sha256.c sha256_transform()
implementation so that it can be used with unaligned buffers too,
making it more generic.
And use memzero_explicit for better clearing of sensitive data.
Note unlike other patches in this series this commit actually makes
functi
Drop the duplicate sha256_transform function from crypto/sha256_generic.c
and use the implementation from lib/crypto/sha256.c instead.
"diff -u lib/crypto/sha256.c sha256_generic.c"
shows that both implementations are identical.
Signed-off-by: Hans de Goede
---
crypto/Kconfig | 1 +
c
Add a bunch of missing spaces after commas and arround operators.
Note the main goal of this is to make sha256_transform and its helpers
identical in formatting too the duplcate implementation in lib/sha256.c,
so that "diff -u" can be used to compare them to prove that no functional
changes are ma
Before this commit lib/crypto/sha256.c has only been used in the s390 and
x86 purgatory code, make it suitable for generic use:
* Export interesting symbols
* Add -D__DISABLE_EXPORTS to CFLAGS_sha256.o for purgatory builds to
avoid the exports for the purgatory builds
* Add to lib/crypto/Makefi
Generic crypto implementations belong under lib/crypto not directly in
lib, likewise the header should be in include/crypto, not include/linux.
Note that the code in lib/crypto/sha256.c is not yet available for
generic use after this commit, it is still only used by the s390 and x86
purgatory code
For some reason after the first 15 steps the last statement of each
step ends with "t1+t2", missing spaces around the "+". This commit
fixes this. This was done with a 's/= t1+t2/= t1 + t2/' to make sure
no functional changes are introduced.
Note the main goal of this is to make lib/sha256.c's sha
Hi All,
Here is a patch series refactoring the current 2 separate SHA256
C implementations into 1 and put it into a separate library.
There are 2 reasons for this:
1) Remove the code duplication of having 2 separate implementations
2) Offer a separate library SHA256 implementation which can be
For correctness and compliance with the XTS-AES specification, we are
adding support for ciphertext stealing to XTS implementations, even
though no use cases are known that will be enabled by this.
Since the Power8 implementation already has a fallback skcipher standby
for other purposes, let's us
For correctness and compliance with the XTS-AES specification, we are
adding support for ciphertext stealing to XTS implementations, even
though no use cases are known that will be enabled by this.
Since the s390 implementation already has a fallback skcipher standby
for other purposes, let's use
Align the x86 code with the generic XTS template, which now supports
ciphertext stealing as described by the IEEE XTS-AES spec P1619.
Tested-by: Stephan Mueller
Signed-off-by: Ard Biesheuvel
---
v2: - move 'decrypt' flag from glue ctx struct to function prototype
- remove redundant goto
On Fri, 16 Aug 2019 at 13:22, Stephan Mueller wrote:
>
> Am Freitag, 16. August 2019, 12:10:21 CEST schrieb Ard Biesheuvel:
>
> Hi Ard,
>
> > Align the x86 code with the generic XTS template, which now supports
> > ciphertext stealing as described by the IEEE XTS-AES spec P1619.
>
> After applying
Am Freitag, 16. August 2019, 12:10:21 CEST schrieb Ard Biesheuvel:
Hi Ard,
> Align the x86 code with the generic XTS template, which now supports
> ciphertext stealing as described by the IEEE XTS-AES spec P1619.
After applying the patch, the boot is successful even with the extra tests.
>
> Si
On Fri, 16 Aug 2019 at 13:10, Ard Biesheuvel wrote:
>
> Align the x86 code with the generic XTS template, which now supports
> ciphertext stealing as described by the IEEE XTS-AES spec P1619.
>
> Signed-off-by: Ard Biesheuvel
Oops, $SUBJECT should be x86/xts rather than aes/xts
> ---
> arch/x8
Align the x86 code with the generic XTS template, which now supports
ciphertext stealing as described by the IEEE XTS-AES spec P1619.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/aesni-intel_glue.c | 1 +
arch/x86/crypto/camellia_aesni_avx2_glue.c | 1 +
arch/x86/crypto/camellia_a
Am Freitag, 16. August 2019, 11:52:33 CEST schrieb Ard Biesheuvel:
Hi Ard,
> On Fri, 16 Aug 2019 at 12:50, Stephan Müller wrote:
> > Hi,
> >
> > with the current cryptodev-2.6 code, I get the following with fips=1:
> >
> > [ 22.301826] alg: skcipher: xts-aes-aesni encryption failed on test
>
On Fri, 16 Aug 2019 at 12:50, Stephan Müller wrote:
>
> Hi,
>
> with the current cryptodev-2.6 code, I get the following with fips=1:
>
> [ 22.301826] alg: skcipher: xts-aes-aesni encryption failed on test vector
> "random: len=28 klen=64"; expected_error=0, actual_error=-22, cfg="random:
> inpl
Hi,
with the current cryptodev-2.6 code, I get the following with fips=1:
[ 22.301826] alg: skcipher: xts-aes-aesni encryption failed on test vector
"random: len=28 klen=64"; expected_error=0, actual_error=-22, cfg="random:
inplace may_sleep use_final src_divs=[100.0%@+20] iv_offset=57"
[ 2
On Fri, 16 Aug 2019 at 10:00, Christina Quast
wrote:
>
> Use ccm(aes) aead transform instead of invoking the AES block cipher
> block by block.
>
Thanks! This eliminates another two users of the bare cipher API,
which is not the right abstraction for drivers to use.
Reviewed-by: Ard Biesheuvel
On 2019/8/16 15:08, Ondrej Mosnáček wrote:
> pi 16. 8. 2019 o 9:02 Ondrej Mosnáček napísal(a):
>> Hi Herbert,
>>
>> pi 16. 8. 2019 o 1:52 Herbert Xu napísal(a):
>>> On Thu, Aug 15, 2019 at 10:17:37PM +0800, Zhou Wang wrote:
> - dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u: %u-%pa
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Signed-off-by: Christina Quast
---
drivers/staging/rtl8192e/Kconfig | 1 +
drivers/staging/rtl8192e/rtllib_crypt_ccmp.c | 187 ---
2 files changed, 78 insertions(+), 110 deletions(-
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Signed-off-by: Christina Quast
---
drivers/staging/rtl8192u/Kconfig | 2 +
.../rtl8192u/ieee80211/ieee80211_crypt_ccmp.c | 187 --
2 files changed, 81 insertions(+), 108 deletions(
pi 16. 8. 2019 o 9:02 Ondrej Mosnáček napísal(a):
> Hi Herbert,
>
> pi 16. 8. 2019 o 1:52 Herbert Xu napísal(a):
> > On Thu, Aug 15, 2019 at 10:17:37PM +0800, Zhou Wang wrote:
> > >
> > > > - dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u: %u-%pad\n",
> > > > queue,
> > > > - cmd
Use ccm(aes) aead transform instead of invoking the AES block cipher
block by block.
Christina Quast (2):
staging: rtl8192u: ieee80211: ieee80211_crypt_ccmp.c: Use crypto API
ccm(aes)
staging: rtl8192e: rtllib_crypt_ccmp.c: Use crypto API ccm(aes)
drivers/staging/rtl8192e/Kconfig
Hi Herbert,
pi 16. 8. 2019 o 1:52 Herbert Xu napísal(a):
> On Thu, Aug 15, 2019 at 10:17:37PM +0800, Zhou Wang wrote:
> >
> > > - dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u: %u-%pad\n", queue,
> > > - cmd, dma_addr);
> > > + dev_dbg(&qm->pdev->dev, "QM mailbox request to q%u
30 matches
Mail list logo
