Re: [PATCH] crypto: rsa: rename two rsa key files

[yjin]

Thanks for Herbert's reminder.
I have drop this patch in a previous mail.

Regards!
Yanjiang

On 2016年11月08日 20:09, Herbert Xu wrote:

yanjiang@windriver.com wrote:

From: Yanjiang Jin 

This is to eliminate the below compile error:

crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h: No such file or 
directory
#include "rsaprivkey-asn1.h"
 ^
compilation terminated.

Signed-off-by: Yanjiang Jin 

This patch is bogus.  The header files are meant to be generated.
Please find out why they are not being generated in your case.

Thanks,


--
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 RESEND] crypto: gf128mul - remove dead gf128mul_64k_lle code

[Alex Cope]

This code is unlikely to be useful in the future because transforms
don't know how often keys will be changed, new algorithms are unlikely
to use lle representation, and tables should be replaced with
carryless multiplication instructions when available.

Signed-off-by: Alex Cope 
---
 crypto/gf128mul.c | 55 ---
 include/crypto/gf128mul.h | 13 ++-
 2 files changed, 6 insertions(+), 62 deletions(-)

diff --git a/crypto/gf128mul.c b/crypto/gf128mul.c
index 5276607..57c85dd 100644
--- a/crypto/gf128mul.c
+++ b/crypto/gf128mul.c
@@ -263,48 +263,6 @@ EXPORT_SYMBOL(gf128mul_bbe);
  * t[1][BYTE] contains g*x^8*BYTE
  *  ..
  * t[15][BYTE] contains g*x^120*BYTE */
-struct gf128mul_64k *gf128mul_init_64k_lle(const be128 *g)
-{
-   struct gf128mul_64k *t;
-   int i, j, k;
-
-   t = kzalloc(sizeof(*t), GFP_KERNEL);
-   if (!t)
-   goto out;
-
-   for (i = 0; i < 16; i++) {
-   t->t[i] = kzalloc(sizeof(*t->t[i]), GFP_KERNEL);
-   if (!t->t[i]) {
-   gf128mul_free_64k(t);
-   t = NULL;
-   goto out;
-   }
-   }
-
-   t->t[0]->t[128] = *g;
-   for (j = 64; j > 0; j >>= 1)
-   gf128mul_x_lle(>t[0]->t[j], >t[0]->t[j + j]);
-
-   for (i = 0;;) {
-   for (j = 2; j < 256; j += j)
-   for (k = 1; k < j; ++k)
-   be128_xor(>t[i]->t[j + k],
- >t[i]->t[j], >t[i]->t[k]);
-
-   if (++i >= 16)
-   break;
-
-   for (j = 128; j > 0; j >>= 1) {
-   t->t[i]->t[j] = t->t[i - 1]->t[j];
-   gf128mul_x8_lle(>t[i]->t[j]);
-   }
-   }
-
-out:
-   return t;
-}
-EXPORT_SYMBOL(gf128mul_init_64k_lle);
-
 struct gf128mul_64k *gf128mul_init_64k_bbe(const be128 *g)
 {
struct gf128mul_64k *t;
@@ -357,19 +315,6 @@ void gf128mul_free_64k(struct gf128mul_64k *t)
 }
 EXPORT_SYMBOL(gf128mul_free_64k);
 
-void gf128mul_64k_lle(be128 *a, struct gf128mul_64k *t)
-{
-   u8 *ap = (u8 *)a;
-   be128 r[1];
-   int i;
-
-   *r = t->t[0]->t[ap[0]];
-   for (i = 1; i < 16; ++i)
-   be128_xor(r, r, >t[i]->t[ap[i]]);
-   *a = *r;
-}
-EXPORT_SYMBOL(gf128mul_64k_lle);
-
 void gf128mul_64k_bbe(be128 *a, struct gf128mul_64k *t)
 {
u8 *ap = (u8 *)a;
diff --git a/include/crypto/gf128mul.h b/include/crypto/gf128mul.h
index da2530e..b611aa9 100644
--- a/include/crypto/gf128mul.h
+++ b/include/crypto/gf128mul.h
@@ -181,20 +181,19 @@ static inline void gf128mul_free_4k(struct gf128mul_4k *t)
 }
 
 
-/* 64k table optimization, implemented for lle and bbe */
+/* 64k table optimization, implemented for bbe */
 
 struct gf128mul_64k {
struct gf128mul_4k *t[16];
 };
 
-/* first initialize with the constant factor with which you
- * want to multiply and then call gf128_64k_lle with the other
- * factor in the first argument, the table in the second and a
- * scratch register in the third. Afterwards *a = *r. */
-struct gf128mul_64k *gf128mul_init_64k_lle(const be128 *g);
+/* First initialize with the constant factor with which you
+ * want to multiply and then call gf128mul_64k_bbe with the other
+ * factor in the first argument, and the table in the second.
+ * Afterwards, the result is stored in *a.
+ */
 struct gf128mul_64k *gf128mul_init_64k_bbe(const be128 *g);
 void gf128mul_free_64k(struct gf128mul_64k *t);
-void gf128mul_64k_lle(be128 *a, struct gf128mul_64k *t);
 void gf128mul_64k_bbe(be128 *a, struct gf128mul_64k *t);
 
 #endif /* _CRYPTO_GF128MUL_H */
-- 
2.8.0.rc3.226.g39d4020

--
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: dh - Consistenly return negative error codes

[Mat Martineau]

Fix the single instance where a positive EINVAL was returned.

Signed-off-by: Mat Martineau 
---
 crypto/dh.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/crypto/dh.c b/crypto/dh.c
index 9d19360..ddcb528 100644
--- a/crypto/dh.c
+++ b/crypto/dh.c
@@ -118,7 +118,7 @@ static int dh_compute_value(struct kpp_request *req)
if (req->src) {
base = mpi_read_raw_from_sgl(req->src, req->src_len);
if (!base) {
-   ret = EINVAL;
+   ret = -EINVAL;
goto err_free_val;
}
} else {
-- 
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: [PATCH v4] poly1305: generic C can be faster on chips with slow unaligned access

[Eric Biggers]

On Tue, Nov 08, 2016 at 08:52:39AM +0100, Martin Willi wrote:
> 
> 
> Not sure what the exact alignment rules for key/iv are, but maybe we
> want to replace the same function in chacha20_generic.c as well?
> 
> Martin

chacha20-generic provides a blkcipher API and sets an alignmask of sizeof(u32)
- 1.  This applies to the key buffer for ->setkey() and to the mapped addresses
for the input/output buffers and IV during the blkcipher walk.  So it does not
appear to have the problems that poly1305 has.  

I do however see one small problem which is that
'u8 stream[CHACHA20_BLOCK_SIZE];' is, strictly speaking, not guaranteed to be
aligned to u32.

Eric
--
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 6/6] Add support for AEAD algos.

[Harsh Jain]

On 08-11-2016 18:29, Stephan Mueller wrote:
> Am Dienstag, 8. November 2016, 17:16:38 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
>> On 08-11-2016 16:45, Stephan Mueller wrote:
>>> Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:
>>>
>>> Hi Harsh,
>>>
>> +static void chcr_verify_tag(struct aead_request *req, u8 *input, int
>> *err)
>> +{
>> +u8 temp[SHA512_DIGEST_SIZE];
>> +struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>> +int authsize = crypto_aead_authsize(tfm);
>> +struct cpl_fw6_pld *fw6_pld;
>> +int cmp = 0;
>> +
>> +fw6_pld = (struct cpl_fw6_pld *)input;
>> +if ((get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) 
>> ||
>> +(get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_GCM)) {
>> +cmp = memcmp(_pld->data[2], (fw6_pld + 1), 
>> authsize);
>> +} else {
>> +
>> +sg_pcopy_to_buffer(req->src, sg_nents(req->src), temp,
>> +authsize, req->assoclen +
>> +req->cryptlen - authsize);
> I am wondering whether the math is correct here in any case. It is
> permissible that we have an AAD size of 0 and even a zero-sized
> ciphertext. How is such scenario covered here?
 Here we are trying to copy user supplied tag to local buffer(temp) for
 decrypt operation only. relative index of tag in src sg list will not
 change when AAD is zero and in decrypt operation cryptlen > authsize.
>>> I am just wondering where this is checked. Since all of these
>>> implementations are directly accessible from unprivileged user space, we
>>> should be careful.
>> chcr_verify_tag() will be called when req->verify is set to "VERIFY_SW", 
>> same will set in decrypt callback function of Algo(like chcr_aead_decrypt)
>> only. It will ensure calling of chcr_verify_tag() in de-crypt operation
>> only.
> I think that limiting to the decryption path may not be enough. What happens 
> if a caller sets some assoclen, but when invoking the decryption operation it 
> provides input data that is smaller than the assoclen? The API allows this 
> scenario.
If I understand correctly, in this case passed sg list will be smaller. We 
should return with error -EINVAL at entry point only (like create_gcm_wr), 
control should not reach to chcr_verify_tag().

>
> Ciao
> Stephan

--
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 6/6] Add support for AEAD algos.

[Stephan Mueller]

Am Dienstag, 8. November 2016, 17:16:38 CET schrieb Harsh Jain:

Hi Harsh,

> On 08-11-2016 16:45, Stephan Mueller wrote:
> > Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:
> > 
> > Hi Harsh,
> > 
>  +static void chcr_verify_tag(struct aead_request *req, u8 *input, int
>  *err)
>  +{
>  +u8 temp[SHA512_DIGEST_SIZE];
>  +struct crypto_aead *tfm = crypto_aead_reqtfm(req);
>  +int authsize = crypto_aead_authsize(tfm);
>  +struct cpl_fw6_pld *fw6_pld;
>  +int cmp = 0;
>  +
>  +fw6_pld = (struct cpl_fw6_pld *)input;
>  +if ((get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) 
>  ||
>  +(get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_GCM)) {
>  +cmp = memcmp(_pld->data[2], (fw6_pld + 1), 
>  authsize);
>  +} else {
>  +
>  +sg_pcopy_to_buffer(req->src, sg_nents(req->src), temp,
>  +authsize, req->assoclen +
>  +req->cryptlen - authsize);
> >>> 
> >>> I am wondering whether the math is correct here in any case. It is
> >>> permissible that we have an AAD size of 0 and even a zero-sized
> >>> ciphertext. How is such scenario covered here?
> >> 
> >> Here we are trying to copy user supplied tag to local buffer(temp) for
> >> decrypt operation only. relative index of tag in src sg list will not
> >> change when AAD is zero and in decrypt operation cryptlen > authsize.
> > 
> > I am just wondering where this is checked. Since all of these
> > implementations are directly accessible from unprivileged user space, we
> > should be careful.
> chcr_verify_tag() will be called when req->verify is set to "VERIFY_SW", 
> same will set in decrypt callback function of Algo(like chcr_aead_decrypt)
> only. It will ensure calling of chcr_verify_tag() in de-crypt operation
> only.

I think that limiting to the decryption path may not be enough. What happens 
if a caller sets some assoclen, but when invoking the decryption operation it 
provides input data that is smaller than the assoclen? The API allows this 
scenario.

Ciao
Stephan
--
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] crypto: rsa: rename two rsa key files

[Herbert Xu]

yanjiang@windriver.com wrote:
> From: Yanjiang Jin 
> 
> This is to eliminate the below compile error:
> 
> crypto/rsa_helper.c:19:29: fatal error: rsaprivkey-asn1.h: No such file or 
> directory
> #include "rsaprivkey-asn1.h"
> ^
> compilation terminated.
> 
> Signed-off-by: Yanjiang Jin 

This patch is bogus.  The header files are meant to be generated.
Please find out why they are not being generated in your case.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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] crypto: gf128mul - remove dead gf128mul_64k_lle code

[Herbert Xu]

Alex Cope  wrote:
> This code is unlikely to be useful in the future because transforms
> don't know how often keys will be changed, new algorithms are unlikely
> to use lle representation, and tables should be replaced with
> carryless multiplication instructions when available.
> 
> Signed-off-by: Alex Cope 

Your patch doesn't apply.  Please fix it and resubmit.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 6/6] Add support for AEAD algos.

[Harsh Jain]

On 08-11-2016 16:45, Stephan Mueller wrote:
> Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:
>
> Hi Harsh,
>
 +static void chcr_verify_tag(struct aead_request *req, u8 *input, int
 *err)
 +{
 +  u8 temp[SHA512_DIGEST_SIZE];
 +  struct crypto_aead *tfm = crypto_aead_reqtfm(req);
 +  int authsize = crypto_aead_authsize(tfm);
 +  struct cpl_fw6_pld *fw6_pld;
 +  int cmp = 0;
 +
 +  fw6_pld = (struct cpl_fw6_pld *)input;
 +  if ((get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) ||
 +  (get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_GCM)) {
 +  cmp = memcmp(_pld->data[2], (fw6_pld + 1), authsize);
 +  } else {
 +
 +  sg_pcopy_to_buffer(req->src, sg_nents(req->src), temp,
 +  authsize, req->assoclen +
 +  req->cryptlen - authsize);
>>> I am wondering whether the math is correct here in any case. It is
>>> permissible that we have an AAD size of 0 and even a zero-sized
>>> ciphertext. How is such scenario covered here?
>> Here we are trying to copy user supplied tag to local buffer(temp) for
>> decrypt operation only. relative index of tag in src sg list will not
>> change when AAD is zero and in decrypt operation cryptlen > authsize.
> I am just wondering where this is checked. Since all of these implementations 
> are directly accessible from unprivileged user space, we should be careful.
chcr_verify_tag() will be called when req->verify is set to "VERIFY_SW",  same 
will set in decrypt callback function of Algo(like chcr_aead_decrypt) only. It 
will ensure calling of chcr_verify_tag() in de-crypt operation only.


>
 +  cmp = memcmp(temp, (fw6_pld + 1), authsize);
>>> I would guess in both cases memcmp should be replaced with crypto_memneq
>> Yes can be done
>>
 +  }
 +  if (cmp)
 +  *err = -EBADMSG;
 +  else
 +  *err = 0;
>>> What do you think about memzero_explicit(tmp)?
>> No Idea why we needs explicitly setting of zero for local variable.  Please
>> share some online resources to understand this.
> In dumps, the stack is also produced. Yet I see that stack memory is very 
> volatile and thus will be overwritten soon. Thus my common approach for 
> sensitive data is that heap variables must be zeroized. Stack variables are 
> suggested to be zeroized. As far as I understand the code, temp will hold a 
> copy of the tag value, i.e. a public piece of information. If this is 
> correct, 
> that I concur that a memset may not be needed after all.
Yes, temp contains user supplied tag. We can ignore memset here. I will review 
the other function weather they need similar memset or not.
>
> Ciao
> Stephan

--
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 6/6] Add support for AEAD algos.

[Stephan Mueller]

Am Donnerstag, 27. Oktober 2016, 15:36:08 CET schrieb Harsh Jain:

Hi Harsh,

> >> +static void chcr_verify_tag(struct aead_request *req, u8 *input, int
> >> *err)
> >> +{
> >> +  u8 temp[SHA512_DIGEST_SIZE];
> >> +  struct crypto_aead *tfm = crypto_aead_reqtfm(req);
> >> +  int authsize = crypto_aead_authsize(tfm);
> >> +  struct cpl_fw6_pld *fw6_pld;
> >> +  int cmp = 0;
> >> +
> >> +  fw6_pld = (struct cpl_fw6_pld *)input;
> >> +  if ((get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_RFC4106) ||
> >> +  (get_aead_subtype(tfm) == CRYPTO_ALG_SUB_TYPE_AEAD_GCM)) {
> >> +  cmp = memcmp(_pld->data[2], (fw6_pld + 1), authsize);
> >> +  } else {
> >> +
> >> +  sg_pcopy_to_buffer(req->src, sg_nents(req->src), temp,
> >> +  authsize, req->assoclen +
> >> +  req->cryptlen - authsize);
> > 
> > I am wondering whether the math is correct here in any case. It is
> > permissible that we have an AAD size of 0 and even a zero-sized
> > ciphertext. How is such scenario covered here?
> 
> Here we are trying to copy user supplied tag to local buffer(temp) for
> decrypt operation only. relative index of tag in src sg list will not
> change when AAD is zero and in decrypt operation cryptlen > authsize.

I am just wondering where this is checked. Since all of these implementations 
are directly accessible from unprivileged user space, we should be careful.

> >> +  cmp = memcmp(temp, (fw6_pld + 1), authsize);
> > 
> > I would guess in both cases memcmp should be replaced with crypto_memneq
> 
> Yes can be done
> 
> >> +  }
> >> +  if (cmp)
> >> +  *err = -EBADMSG;
> >> +  else
> >> +  *err = 0;
> > 
> > What do you think about memzero_explicit(tmp)?
> 
> No Idea why we needs explicitly setting of zero for local variable.  Please
> share some online resources to understand this.

In dumps, the stack is also produced. Yet I see that stack memory is very 
volatile and thus will be overwritten soon. Thus my common approach for 
sensitive data is that heap variables must be zeroized. Stack variables are 
suggested to be zeroized. As far as I understand the code, temp will hold a 
copy of the tag value, i.e. a public piece of information. If this is correct, 
that I concur that a memset may not be needed after all.

Ciao
Stephan
--
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 v4] poly1305: generic C can be faster on chips with slow unaligned access

[Martin Willi]

> By using the unaligned access helpers, we drastically improve
> performance on small MIPS routers that have to go through the
> exception fix-up handler for these unaligned accesses.

I couldn't measure any slowdown here, so:

Acked-by: Martin Willi 

> -   dctx->s[0] = le32_to_cpuvp(key +  0);
> +   dctx->s[0] = get_unaligned_le32(key +  0);

Not sure what the exact alignment rules for key/iv are, but maybe we
want to replace the same function in chacha20_generic.c as well?

Martin
--
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