Re: [RFC PATCH v2] crypto: Add IV generation algorithms

[Binoy Jayan]

Hi Gilad,

On 3 January 2017 at 19:53, Gilad Ben-Yossef  wrote:
> Good idea. I wanted to test the patch but alas it does not apply cleanly.
> You seem to have a blank line at the end of files and other small
> transgressions that makes checkpatch grumpy.

I think that is because there were some key structure changes in dm-crypt
after I sent out v2. I have resolved them while working on v3. Please wait for
the next version of the patchset. I'll send it probably by next week.
I wanted to incorporate a few changes suggested by Herbert before sending them.

> What is Not-signed-off-by ? :-)

It was just an RFC patch, not ready for merging.

Thanks,
Binoy
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: mediatek: don't return garbage err on successful return

[Colin King]

From: Colin Ian King 

In the case where keylen <= bs mtk_sha_setkey returns an uninitialized
return value in err.  Fix this by returning 0 instead of err.

Issue detected by static analysis with cppcheck.

Signed-off-by: Colin Ian King 
---
 drivers/crypto/mediatek/mtk-sha.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/mediatek/mtk-sha.c 
b/drivers/crypto/mediatek/mtk-sha.c
index 8951363..8e1b440 100644
--- a/drivers/crypto/mediatek/mtk-sha.c
+++ b/drivers/crypto/mediatek/mtk-sha.c
@@ -878,7 +878,7 @@ static int mtk_sha_setkey(struct crypto_ahash *tfm,
bctx->opad[i] ^= 0x5c;
}
 
-   return err;
+   return 0;
 }
 
 static int mtk_sha_export(struct ahash_request *req, void *out)
-- 
2.10.2

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH v2] crypto: Add IV generation algorithms

[Gilad Ben-Yossef]

Hi Binoy,

On Tue, Dec 13, 2016 at 02:19:09PM +0530, Binoy Jayan wrote:
> Currently, the iv generation algorithms are implemented in dm-crypt.c.
> The goal is to move these algorithms from the dm layer to the kernel
> crypto layer by implementing them as template ciphers so they can be
> implemented in hardware for performance. As part of this patchset, the
> iv-generation code is moved from the dm layer to the crypto layer and
> adapt the dm-layer to send a whole 'bio' (as defined in the block layer)
> at a time. Each bio contains the in memory representation of physically
> contiguous disk blocks. The dm layer sets up a chained scatterlist of
> these blocks split into physically contiguous segments in memory so that
> DMA can be performed. The iv generation algorithms implemented in geniv.c
> include plain, plain64, essiv, benbi, null, lmk and tcw.
>

Good idea. I wanted to test the patch but alas it does not apply cleanly.
You seem to have a blank line at the end of files and other small
transgressions that makes checkpatch grumpy.



Also...

>
> Not-signed-off-by: Binoy Jayan 


What is Not-signed-off-by ? :-)

Thanks,
Gilad Ben-Yossef
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Geode LX AES/RNG driver triggers warning

[One Thousand Gnomes]

On Sat, 31 Dec 2016 00:58:54 +0100
David Gstir  wrote:

> Hi!
> 
> I recently tested kernel v4.9 on my AMD Geode platform and noticed that its 
> AES hardware driver triggers this warning on initialization:

...

> I narrowed it down to commit 6e9b5e76882c ("hwrng: geode - Migrate to managed 
> API") which seems to introduce this. It looks to me like some issue between 
> devres, the Geode hwrng and AES drivers which both use the same PCI device.

It does

> I'm no expert here, but I curious if this will cause any issues when using 
> the hardware crypto drivers and also what's the best way to get rid of this?

Probably to create an mfd device that turns the PCI device into two MFD
devices and bind AES and hwrng one to each MFD device. Take a look in
drivers/mfd. That would also fix the uglies in mod_init for the rng
driver.

Alan


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] crypto: ARM/arm64 - AES and ChaCha20 updates for v4.11

[Ard Biesheuvel]

On 2 January 2017 at 18:21, Ard Biesheuvel  wrote:
> This series adds SIMD implementations for arm64 and ARM of ChaCha20 (*),
> and a port of the ARM bit-sliced AES algorithm to arm64, and
>
> Patch #1 is a prerequisite for the AES-XTS implementation in #6, which needs
> a secondary AES transform to generate the initial tweak.
>

Herbert,

I actually have a scalar AES implementation for arm64 which I could
use instead, making this patch unnecessary.

I could respin the entire series, or you could simply disregard #1 and
#6 for now, whichever you prefer.

Thanks,
Ard.


> Patch #2 optimizes the bit-sliced AES glue code for ARM to iterate over the
> input in the most efficient manner possible.
>
> Patch #3 adds a NEON implementation of ChaCha20 for ARM.
>
> Patch #4 adds a NEON implementation of ChaCha20 for arm64.
>
> Patch #5 modifies the existing NEON and ARMv8 Crypto Extensions 
> implementations
> of AES-CTR to be available as a synchronous skcipher as well. This is intended
> for the mac80211 code, which uses synchronous encapsulations of ctr(aes)
> [ccm, gcm] in softirq context, which supports SIMD algorithms on arm64.
>
> Patch #6 adds a port of the ARM bit-sliced AES code to arm64, in ECB, CTR
> and XTS modes.
>
> Ard Biesheuvel (6):
>   crypto: generic/aes - export encrypt and decrypt entry points
>   crypto: arm/aes-neonbs - process 8 blocks in parallel if we can
>   crypto: arm/chacha20 - implement NEON version based on SSE3 code
>   crypto: arm64/chacha20 - implement NEON version based on SSE3 code
>   crypto: arm64/aes-blk - expose AES-CTR as synchronous cipher as well
>   crypto: arm64/aes - reimplement bit-sliced ARM/NEON implementation for
> arm64
>
>  arch/arm/crypto/Kconfig|   6 +
>  arch/arm/crypto/Makefile   |   2 +
>  arch/arm/crypto/aesbs-glue.c   |  67 +-
>  arch/arm/crypto/chacha20-neon-core.S   | 524 
>  arch/arm/crypto/chacha20-neon-glue.c   | 128 +++
>  arch/arm64/crypto/Kconfig  |  13 +
>  arch/arm64/crypto/Makefile |   6 +
>  arch/arm64/crypto/aes-glue.c   |  25 +-
>  arch/arm64/crypto/aes-neonbs-core.S| 879 
>  arch/arm64/crypto/aes-neonbs-glue.c| 344 
>  arch/arm64/crypto/chacha20-neon-core.S | 450 ++
>  arch/arm64/crypto/chacha20-neon-glue.c | 127 +++
>  crypto/aes_generic.c   |  10 +-
>  include/crypto/aes.h   |   3 +
>  14 files changed, 2549 insertions(+), 35 deletions(-)
>  create mode 100644 arch/arm/crypto/chacha20-neon-core.S
>  create mode 100644 arch/arm/crypto/chacha20-neon-glue.c
>  create mode 100644 arch/arm64/crypto/aes-neonbs-core.S
>  create mode 100644 arch/arm64/crypto/aes-neonbs-glue.c
>  create mode 100644 arch/arm64/crypto/chacha20-neon-core.S
>  create mode 100644 arch/arm64/crypto/chacha20-neon-glue.c
>
> --
> 2.7.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html