On Sun, Oct 25, 2020 at 10:31:13AM -0400, Arvind Sankar wrote:
> Patch 1/2 -- Use memzero_explicit() instead of structure assignment/plain
> memset() to clear sensitive state.
>
> Patch 3 -- Currently the temporary variables used in the generic sha256
> implementation are cleared, but the clearing
On Thu, Oct 15, 2020 at 10:23:02AM +0800, Longfang Liu wrote:
> This patchset fixes some coding style.
>
> Longfang Liu (2):
> crypto: hisilicon - delete unused structure member variables
> crypto: hisilicon - fixes some coding style
>
> drivers/crypto/hisilicon/sec2/sec.h| 2 --
>
Eric Biggers wrote:
> From: Eric Biggers
>
> Commit 1d2c3279311e ("crypto: x86/aes - drop scalar assembler
> implementations") was meant to remove aes_glue.c, but it actually left
> it as an unused one-line file. Remove this unused file.
>
> Cc: Ard Biesheuvel
> Signed-off-by: Eric Biggers
>
On Thu, Oct 15, 2020 at 05:24:41PM +0800, Tianjia Zhang wrote:
> This is an algorithm optimization. The reset operation when
> setting the public key is repeated and redundant, so remove it.
> At the same time, `sm2_ecc_os2ec()` is optimized to make the
> function more simpler and more in line with
On Fri, Oct 16, 2020 at 05:05:36PM +0800, Zhang Qilong wrote:
> pm_runtime_get_sync() will increment pm usage counter even
> when it returns an error code. We should call put operation
> in error handling paths of omap_aes_hw_init.
>
> Signed-off-by: Zhang Qilong
> ---
> drivers/crypto/omap-aes
On Fri, Oct 09, 2020 at 09:19:38AM +0100, Shiju Jose wrote:
> Fix following warnings caused by mismatch between
> function parameters and function comments.
>
> drivers/crypto/hisilicon/sgl.c:256: warning: Excess function parameter
> 'hw_sgl_dma' description in 'hisi_acc_sg_buf_unmap'
> drivers/c
On Mon, Oct 12, 2020 at 09:38:16PM +0100, Giovanni Cabiddu wrote:
> This set is an initial rework of the QAT driver in preparation for the
> inclusion of the qat_4xxx driver (QAT GEN4).
>
> Summary of changes:
> * IV update logic moved to software to remove allocation of the IV
> buffer in t
On Sat, Oct 10, 2020 at 05:47:36PM +0100, Colin King wrote:
> From: Colin Ian King
>
> An incorrect sizeof() is being used, sizeof(priv->ring[i].rdr_req) is
> not correct, it should be sizeof(*priv->ring[i].rdr_req). Note that
> since the size of ** is the same size as * this is not causing any
>
On Thu, Oct 08, 2020 at 09:34:56AM +, Christophe Leroy wrote:
> current_desc_hdr() returns a u32 but in fact this is a __be32,
> leading to a lot of sparse warnings.
>
> Change the return type to __be32 and ensure it is handled as
> sure by the caller.
>
> Fixes: 3e721aeb3df3 ("crypto: talito
On Thu, Oct 08, 2020 at 09:34:55AM +, Christophe Leroy wrote:
> current_desc_hdr() compares the value of the current descriptor
> with the next_desc member of the talitos_desc struct.
>
> While the current descriptor is obtained from in_be32() which
> return CPU ordered bytes, next_desc member
On Wed, Oct 07, 2020 at 01:43:45PM +0100, Giovanni Cabiddu wrote:
> Remove unused function qat_dh_get_params().
> This is to fix the following warning when compiling the driver with
> CC=clang W=1
>
> drivers/crypto/qat/qat_common/qat_asym_algs.c:207:34: warning: unused
> function 'qat_dh_get
Like the old __section macro, the __alias macro uses macro # stringification
to create quotes around the symbol name used in the __attribute__.
This can cause differences between gcc and clang when the stringification
itself contains a quote character. So avoid these differences by always
using q
On Wed, 23 Sep 2020 at 13:03, Ben Greear wrote:
>
> On 8/4/20 12:45 PM, 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 Thu, Oct 29, 2020 at 16:48:30 +0100, Krzysztof Kozlowski wrote:
> Fix W=1 compile warnings (invalid kerneldoc):
>
> crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter
> or member 'kid1' not described in 'asymmetric_key_id_same'
> crypto/asymmetric_keys/asymmetric
Fix W=1 compile warnings (invalid kerneldoc):
crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter
or member 'kid1' not described in 'asymmetric_key_id_same'
crypto/asymmetric_keys/asymmetric_type.c:160: warning: Function parameter
or member 'kid2' not described in '
> (+ Andy)
Thanks! Applied to cryptogams, pinged openssl. Cheers.
Replace the explicit EBOIV handling in the dm-crypt driver with calls
into the crypto API, which now possesses the capability to perform
this processing within the crypto subsystem.
Signed-off-by: Gilad Ben-Yossef
---
drivers/md/dm-crypt.c | 61 ++-
1 fil
BitLocker eboiv support, which was removed in
commit 1d8b41ff6991 ("crypto: ccree - remove bitlocker cipher")
is reintroduced based on the crypto API new support for
eboiv.
Signed-off-by: Gilad Ben-Yossef
Fixes: 1d8b41ff6991 ("crypto: ccree - remove bitlocker cipher")
---
drivers/crypto/ccree/cc
Add test vectors for the use of the EBOIV template with cbc(aes)
modes as it is being used by dm-crypt for BitLocker support.
Vectors taken from dm-crypt test suite images.
Signed-off-by: Gilad Ben-Yossef
---
crypto/tcrypt.c | 9 ++
crypto/testmgr.c | 6 +
crypto/testmgr.h | 279 ++
This series creates an EBOIV template that produces a skcipher
transform which passes through all operations to the skcipher, while
using the same skcipher and key to encrypt the input IV, which is
assumed to be a sector offset, although this is not enforced.
This matches dm-crypt use of EBOIV t
Encrypted byte-offset initialization vector (EBOIV) is an IV
generation method that is used in some cases by dm-crypt for
supporting the BitLocker volume encryption used by Windows 8
and onwards as a backwards compatible version in lieu of XTS
support. Support for eboiv was added to dm-crypt in 5.6
On Wed, Oct 28, 2020 at 10:06:58AM +0100, Ard Biesheuvel wrote:
>
> Not sure what is happening here: IIRC the intention was to rely on the
> fact that only the sync cbc(aes) implementation needs the fallback,
> and therefore, allocating a sync skcipher explicitly would avoid this
> recursion.
>
>
On Wed, Oct 28, 2020 at 01:41:28PM +0200, Gilad Ben-Yossef wrote:
>
> Sorry if I'm being daft, but what did you refer to be "an existing
> option"? there was no CONFIG_EBOIV before my patchset, it was simply
> built as part of dm-crypt so it seems that setting CONFIG_EBOIV
> default to dm-crypto Kc
On Fri, Oct 23, 2020 at 02:53:29PM -0700, Eric Biggers wrote:
>
> It's doubtful that anyone will do a global conversion from memset() to
> memzero_explicit(), as it's too hard to find all the places that should be
> converted. They are in lots of different subsystems; the crypto subsystem
> will
24 matches
Mail list logo
