On 10 May 2017 at 01:20, Eric Biggers wrote:
> From: Eric Biggers
>
> mix_columns() contains a comment which shows the matrix used by the
> MixColumns step of AES, but the last entry in this matrix was incorrect
> --- and did not match the code, which is correct. Fix the comment.
>
> Signed-off-
ecc software implementation works with chunks of u64 data. There were some
unnecessary casts to u8 and then back to u64 for the ecc keys. Remove the
unncessary casts.
Tudor Ambarus (4):
crypto: ecc - remove unused function arguments
crypto: ecc - remove casts in ecdh_make_pub_key
crypto: ecc
ecc software implementation works with chunks of u64 data. There were some
unnecessary casts to u8 and then back to u64 for the ecc keys. This patch
removes the unncessary casts.
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 12 ++--
crypto/ecc.h | 4 ++--
crypto/ecdh.c | 6 +++---
ecc software implementation works with chunks of u64 data. There were some
unnecessary casts to u8 and then back to u64 for the ecc keys. This patch
removes the unncessary casts.
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 10 --
crypto/ecc.h | 2 +-
crypto/ecdh.c | 3 +--
3 file
ecc software implementation works with chunks of u64 data. There were some
unnecessary casts to u8 and then back to u64 for the ecc keys. This patch
removes the unncessary casts.
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 6 +++---
crypto/ecc.h | 2 +-
crypto/ecdh.c | 2 +-
3 files change
Signed-off-by: Tudor Ambarus
---
crypto/ecc.c | 8 +++-
crypto/ecc.h | 13 +++--
crypto/ecdh.c | 11 +--
3 files changed, 11 insertions(+), 21 deletions(-)
diff --git a/crypto/ecc.c b/crypto/ecc.c
index 414c78a..69b4cc4 100644
--- a/crypto/ecc.c
+++ b/crypto/ecc.c
@@ -928,
The function should return minimum size for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/ecdh.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/crypto/ecdh.c b/crypto/ecdh.c
index 63ca337..01bfd13 100644
--- a/crypto/ecdh.c
The function should return minimum size for output buffer
or error code if key hasn't been set.
Signed-off-by: Tudor Ambarus
---
crypto/dh.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/dh.c b/crypto/dh.c
index 87e3542..53d17ff 100644
--- a/crypto/dh.c
+++ b/crypto/
From: Colin Ian King
There is a check to see if nbytes < bsize (and a jump to label 'done' if
it is true) inside the proceeding do-while loop so it is impossible for
the second nbytes < bsize check to be true, hence is it redundant and
can be removed. Remove it.
Detected by CoverityScan, CID#712
Hi Herbert,
This series adds support for Cavium CNN55XX crypto adapters.
CNN55XX crypto adapters belongs to Cavium NITROX family series,
able to accelerates both Symmetric and Asymmetric crypto workloads.
These adapters have crypto cores for Symmetric and Asymmetric
crypto operations, and
Add debugfs support in CNN55XX Physical Function driver.
Provides hardware counters and firmware information.
Signed-off-by: Srikanth Jampala
---
drivers/crypto/cavium/nitrox/nitrox_csr.h | 5 ++
drivers/crypto/cavium/nitrox/nitrox_dev.h | 3 +
drivers/crypto/cavium/nitrox/nitrox_main.c |
Add Physical Function driver support for CNN55XX crypto adapters.
CNN55XX adapters belongs to Cavium NITROX family series,
which accelerate both Symmetric and Asymmetric crypto workloads.
These adapters have crypto engines that need firmware
to become operational.
Signed-off-by: Srikanth Jampala
Register the Symmetric crypto algorithms supported by
CNN55XX driver with crypto subsystem.
The following Symmetric crypto algorithms are supported,
- aes with cbc, ecb, cfb, xts, ctr and cts modes
- des3_ede with cbc and ecb modes
Signed-off-by: Srikanth Jampala
---
drivers/crypto/cavium/n
Am Mittwoch, 10. Mai 2017, 15:06:40 CEST schrieb Srikanth Jampala:
Hi Srikanth,
In general: you are using the ablkcipher API. I think it is on its way out and
being replaced with skcipher.
Maybe it makes sense to replace it here too. It could be as simple as s/
ablkcipher/skcipher/g
> +static
Hi Srikanth,
[auto build test ERROR on cryptodev/master]
[also build test ERROR on next-20170510]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Srikanth-Jampala/crypto
Hi Srikanth,
[auto build test WARNING on cryptodev/master]
[also build test WARNING on next-20170510]
[cannot apply to v4.11]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Srikanth-Jampala
On Wed, May 10 2017 at 9:37am -0400,
Gilad Ben-Yossef wrote:
> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni wrote:
> > Hi Keith,
> >
> > Request based dm (dm-req-crypt) is being used for Disk Encryption solution
> > in Android used by Google. Also as i mentioned reverting this fix improves
>
On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer wrote:
> On Wed, May 10 2017 at 9:37am -0400,
> Gilad Ben-Yossef wrote:
>
>> On Wed, May 10, 2017 at 11:49 AM, Neeraj Soni
>> wrote:
>> > Hi Keith,
>> >
>> > Request based dm (dm-req-crypt) is being used for Disk Encryption solution
>> > in Android
On Sat, 2017-05-06 at 15:59 +0300, Gilad Ben-Yossef wrote:
> ima starts several async. crypto ops and waits for their completions.
> Move it over to generic code doing the same.
>
> Signed-off-by: Gilad Ben-Yossef
Acked-by: Mimi Zohar
> ---
> security/integrity/ima/ima_crypto.c | 56
> +
Hi Gilad,
On Sat, May 06, 2017 at 03:59:50PM +0300, Gilad Ben-Yossef wrote:
> Invoking a possibly async. crypto op and waiting for completion
> while correctly handling backlog processing is a common task
> in the crypto API implementation and outside users of it.
>
> This patch re-factors one of
Hi Gilad,
On Sat, May 06, 2017 at 03:59:56PM +0300, Gilad Ben-Yossef wrote:
> int fscrypt_do_page_crypto(const struct inode *inode, fscrypt_direction_t rw,
> u64 lblk_num, struct page *src_page,
> struct page *dest_page, unsigned int len,
> @@ -15
Thanks for inputs folks. So shall i conclude that there is no remedy
available that can be applied on 4.4 and reverting this patch is only
way forward to solve the degradation?
Neeraj
On 5/10/2017 8:25 PM, Gilad Ben-Yossef wrote:
On Wed, May 10, 2017 at 5:45 PM, Mike Snitzer wrote:
On Wed,
Until we move to some latest stable kernel as Keith mentioned.
On 5/11/2017 11:22 AM, Neeraj Soni wrote:
Thanks for inputs folks. So shall i conclude that there is no remedy
available that can be applied on 4.4 and reverting this patch is only
way forward to solve the degradation?
Neeraj
On
23 matches
Mail list logo
