date:20160512

Re: SHA1-MB algorithm broken on latest kernel

2016-05-12 Thread Ingo Molnar


* Herbert Xu  wrote:

> On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote:
> > Hi,
> >  
> > When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
> > observe a panic.
> >  
> > After having a quick look, on reverting the following patches, I am able
> > to complete the booting process.
> > aec4d0e301f17bb143341c82cc44685b8af0b945
> > 8691ccd764f9ecc69a6812dfe76214c86ac9ba06
> > 68874ac3304ade7ed5ebb12af00d6b9bbbca0a16
> >  
> > Of the 3 patches, aec4d0e301f17bb143341c82cc44685b8af0b945 seems wrong.
> > The r10 to r15 registers are used in sha1_x8_avx2.S, which is called
> > from sha1_mb_mgr_flush_avx2.S.
> >
> > I do not think the functionality of the SHA1-MB crypto algorithm has
> > been tested after applying these changes. (I am not sure if any of the
> > other crypto algorithms have been affected by these changes).
> 
> Josh, Ingo:
> 
> Any ideas on this? Should we revert?

Yeah, I think so - although another option would be to standardize 
sha1_x8_avx2() 
- the problem is that it is a function that clobbers registers without 
saving/restoring them, breaking the C function ABI. I realize it's written in 
assembly, but unless there are strong performance reasons to deviate from the 
regular calling convention it might make sense to fix that.

Do any warnings get generated after the revert, if you enable 
CONFIG_STACK_VALIDATION=y?

Thanks,

Ingo
--
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: SHA1-MB algorithm broken on latest kernel

2016-05-12 Thread Herbert Xu

On Thu, May 12, 2016 at 04:31:06PM -0700, Megha Dey wrote:
> Hi,
>  
> When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
> observe a panic.
>  
> After having a quick look, on reverting the following patches, I am able
> to complete the booting process.
> aec4d0e301f17bb143341c82cc44685b8af0b945
> 8691ccd764f9ecc69a6812dfe76214c86ac9ba06
> 68874ac3304ade7ed5ebb12af00d6b9bbbca0a16
>  
> Of the 3 patches, aec4d0e301f17bb143341c82cc44685b8af0b945 seems wrong.
> The r10 to r15 registers are used in sha1_x8_avx2.S, which is called
> from sha1_mb_mgr_flush_avx2.S.
>  
> I do not think the functionality of the SHA1-MB crypto algorithm has
> been tested after applying these changes. (I am not sure if any of the
> other crypto algorithms have been affected by these changes).

Josh, Ingo:

Any ideas on this? Should we revert?

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

SHA1-MB algorithm broken on latest kernel

2016-05-12 Thread Megha Dey

Hi,
 
When booting latest kernel with the CONFIG_CRYPTO_SHA1_MB enabled, I
observe a panic.
 
After having a quick look, on reverting the following patches, I am able
to complete the booting process.
aec4d0e301f17bb143341c82cc44685b8af0b945
8691ccd764f9ecc69a6812dfe76214c86ac9ba06
68874ac3304ade7ed5ebb12af00d6b9bbbca0a16
 
Of the 3 patches, aec4d0e301f17bb143341c82cc44685b8af0b945 seems wrong.
The r10 to r15 registers are used in sha1_x8_avx2.S, which is called
from sha1_mb_mgr_flush_avx2.S.
 
I do not think the functionality of the SHA1-MB crypto algorithm has
been tested after applying these changes. (I am not sure if any of the
other crypto algorithms have been affected by these changes).
 
Thanks,
Megha

--
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 v2] Bluetooth: convert smp and selftest to crypto kpp API

2016-05-12 Thread Benedetto, Salvatore

Hi Johan,

> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Johan Hedberg
> Sent: Thursday, May 12, 2016 7:05 PM
> To: Benedetto, Salvatore 
> Cc: herb...@gondor.apana.org.au; gust...@padovan.org; linux-
> blueto...@vger.kernel.org; linux-crypto@vger.kernel.org;
> mar...@holtmann.org
> Subject: Re: [PATCH v2] Bluetooth: convert smp and selftest to crypto kpp
> API
> 
> Hi Salvatore,
> 
> On Mon, May 09, 2016, Salvatore Benedetto wrote:
> >  * Convert both smp and selftest to crypto kpp API
> >  * Remove module ecc as not more required
> >  * Add ecdh_helper functions for wrapping kpp async calls
> >
> > This patch has been tested *only* with selftest, which is called on
> > module loading. smp-tester passes all tests but the first one, which
> > often times out. Same behavior is observed without this patch though.
> >
> > This patch is based on https://patchwork.kernel.org/patch/9050061/
> >
> > Signed-off-by: Salvatore Benedetto 
> > ---
> >  net/bluetooth/Makefile  |   2 +-
> >  net/bluetooth/ecc.c | 816 
> > 
> >  net/bluetooth/ecc.h |  54 ---
> >  net/bluetooth/ecdh_helper.c | 204 +++
> > net/bluetooth/ecdh_helper.h |  32 ++
> >  net/bluetooth/selftest.c|   6 +-
> >  net/bluetooth/smp.c |   8 +-
> >  7 files changed, 244 insertions(+), 878 deletions(-)  delete mode
> > 100644 net/bluetooth/ecc.c  delete mode 100644 net/bluetooth/ecc.h
> > create mode 100644 net/bluetooth/ecdh_helper.c  create mode 100644
> > net/bluetooth/ecdh_helper.h
> 
> I tried this together with your kpp patches and I was able to successfully 
> pair,
> so from that perspective we're fine and I have no objections for those
> patches being merged.
> 
> There are a couple of things to improve with this patch however:
> 
> The first issue is that you're missing a 'select CRYPTO_ECDH' in
> net/bluetooth/Kconfig. Without this you'll end up creating a kernel that
> either doesn't build or a module that doesn't load.
> 

Right the module won't load. I'll fix this.

> > +#ifndef __ECDH_HELPER_H
> > +#define __ECDH_HELPER_H
> 
> Please leave out these include guards for internal headers. We try to avoid
> them there to force keeping the dependency chains simple. I realize you
> might have copied this from smp.h (which is the only internal header I could
> see having this) so that might need fixing in a separate patch.
> 

Actually I didn't pay much attention to this as I always use them.
I'll remove it.

> > +bool compute_ecdh_shared_secret(const u8 pub_a[64], const u8
> priv_b[32],
> > +   u8 secret[32]);
> > +bool generate_ecdh_key_pair(u8 public_key[64], u8 private_key[32]);
> 
> Could you try to come up with some shorter names than these since they
> cause the line lengths to go past 80 chars. In fact, can't you just keep the
> same names as our ecc.c was using. I don't think those names are taken by
> your new kpp code?

They actually are used internally by the ecc module I reworked.
I'll rename them to compute_ecdh_secret() and generate_ecdh_keys() which
fixes the 80 chars per line issue.

I'll send a v3.

Thanks for reviewing.

Regards,
Salvatore 

--
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 v6 0/3] Key-agreement Protocol Primitives (KPP) API

2016-05-12 Thread Marcel Holtmann

Hi Herbert,

> the following patchset introduces a new API for abstracting key-agreement
> protocols such as DH and ECDH. It provides the primitives required for 
> implementing
> the protocol, thus the name KPP (Key-agreement Protocol Primitives).
> 
> Regards,
> Salvatore
> 
> Changes from v5:
> * Fix ecdh loading in fips mode.
> 
> Changes from v4:
> * If fips_enabled is set allow only P256 (or higher) as Stephan suggested
> * Pass ndigits as argument to ecdh_make_pub_key and ecdh_shared_secret
>  so that VLA can be used like in the rest of the module
> 
> Changes from v3:
> * Move curve ID definition to public header ecdh.h as users need to
>  have access to those ids when selecting the curve
> 
> Changes from v2:
> * Add support for ECDH (curve P192 and P256). I reused the ecc module
>  already present in net/bluetooth and extended it in order to select
>  different curves at runtime. Code for P192 was taken from tinycrypt.
> 
> Changes from v1:
> * Change check in dh_check_params_length based on Stephan review
> 
> 
> Salvatore Benedetto (3):
>  crypto: Key-agreement Protocol Primitives API (KPP)
>  crypto: kpp - Add DH software implementation
>  crypto: kpp - Add ECDH software support

we have tested this with the Bluetooth subsystem to use ECDH for key generation 
and shared secret generation. This seems to work as expected. Feel free to 
merge this patchset.

Acked-by: Marcel Holtmann 

Regards

Marcel

--
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 3/3] crypto: caam - add support for RSA algorithm

2016-05-12 Thread Horia Ioan Geanta Neag

On 5/12/2016 6:06 PM, Tudor Ambarus wrote:
> Add RSA support to caam driver.
> 
> Coauthored-by: Yashpal Dutta 
> 
> Signed-off-by: Tudor Ambarus 
> ---
>  drivers/crypto/caam/Kconfig|  12 ++
>  drivers/crypto/caam/Makefile   |   4 +
>  drivers/crypto/caam/caampkc.c  | 466 
> +
>  drivers/crypto/caam/caampkc.h  |  94 +
>  drivers/crypto/caam/desc.h |   2 +
>  drivers/crypto/caam/pdb.h  |  16 +-
>  drivers/crypto/caam/pkc_desc.c | 138 
>  7 files changed, 731 insertions(+), 1 deletion(-)
>  create mode 100644 drivers/crypto/caam/caampkc.c
>  create mode 100644 drivers/crypto/caam/caampkc.h
>  create mode 100644 drivers/crypto/caam/pkc_desc.c
> 
> diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
> index 5652a53..9ba 100644
> --- a/drivers/crypto/caam/Kconfig
> +++ b/drivers/crypto/caam/Kconfig
> @@ -99,6 +99,18 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
> To compile this as a module, choose M here: the module
> will be called caamhash.
>  
> +config CRYPTO_DEV_FSL_CAAM_PKC_API
> +tristate "Register public key cryptography implementations with 
> Crypto API"
> +depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
> +default y
> +select CRYPTO_RSA
> +help
> +  Selecting this will allow SEC Public key support for RSA.
> +  Supported cryptographic primitives: encryption, decryption,
> +  signature and verification.
> +  To compile this as a module, choose M here: the module
> +  will be called caam_pkc.
> +
>  config CRYPTO_DEV_FSL_CAAM_RNG_API
>   tristate "Register caam device for hwrng API"
>   depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
> diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
> index 550758a..399ad55 100644
> --- a/drivers/crypto/caam/Makefile
> +++ b/drivers/crypto/caam/Makefile
> @@ -5,11 +5,15 @@ ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
>   EXTRA_CFLAGS := -DDEBUG
>  endif
>  
> +ccflags-y += -I$(srctree)/crypto
> +
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
>  obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
> +obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
>  
>  caam-objs := ctrl.o
>  caam_jr-objs := jr.o key_gen.o error.o
> +caam_pkc-y := caampkc.o pkc_desc.o
> diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
> new file mode 100644
> index 000..34ffa87
> --- /dev/null
> +++ b/drivers/crypto/caam/caampkc.c
> @@ -0,0 +1,466 @@
> +/*
> + * caam - Freescale FSL CAAM support for Public Key Cryptography
> + *
> + * Copyright 2016 Freescale Semiconductor, Inc.
> + *
> + * There is no Shared Descriptor for PKC so that the Job Descriptor must 
> carry
> + * all the desired key parameters, input and output pointers.
> + */
> +#include 
> +#include 
> +#include "compat.h"
> +#include "caampkc.h"
> +#include "sg_sw_sec4.h"
> +#include "regs.h"
> +#include "intern.h"
> +#include "jr.h"
> +#include "error.h"
> +
> +static void rsa_io_unmap(struct device *dev, struct rsa_edesc *edesc,
> +  struct akcipher_request *req)
> +{
> + dma_unmap_sg(dev, req->dst, edesc->dst_nents, DMA_FROM_DEVICE);
> + dma_unmap_sg(dev, req->src, edesc->src_nents, DMA_TO_DEVICE);
> +}
> +
> +static void rsa_pub_unmap(struct device *dev, struct rsa_edesc *edesc,
> +   struct akcipher_request *req)
> +{
> + struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
> + struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
> + struct rsa_key *key = >key;
> + struct rsa_pub_desc *hw_desc = (struct rsa_pub_desc *)edesc->hw_desc;
> +
> + dma_unmap_single(dev, hw_desc->n_dma, key->n_sz, DMA_TO_DEVICE);
> + dma_unmap_single(dev, hw_desc->e_dma, key->e_sz, DMA_TO_DEVICE);
> +}
> +
> +static void rsa_priv_f1_unmap(struct device *dev, struct rsa_edesc *edesc,
> +   struct akcipher_request *req)
> +{
> + struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
> + struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
> + struct rsa_key *key = >key;
> + struct rsa_priv_f1_desc *hw_desc =
> + (struct rsa_priv_f1_desc *)edesc->hw_desc;
> +
> + dma_unmap_single(dev, hw_desc->n_dma, key->n_sz, DMA_TO_DEVICE);
> + dma_unmap_single(dev, hw_desc->d_dma, key->n_sz, DMA_TO_DEVICE);
> +}
> +
> +static size_t skip_to_nonzero(u8 *ptr, size_t nbytes)
> +{
> + size_t nr_zeros = 0;
> +
> + while (!(*ptr) && nbytes) {
> + nbytes--;
> + ptr++;
> + nr_zeros++;
> + }
> +
> + return nr_zeros;
> +}
> +
> +static size_t scatterwalk_skip_zeros(struct scatter_walk

Re: [PATCH v2] Bluetooth: convert smp and selftest to crypto kpp API

2016-05-12 Thread Johan Hedberg

Hi Salvatore,

On Mon, May 09, 2016, Salvatore Benedetto wrote:
>  * Convert both smp and selftest to crypto kpp API
>  * Remove module ecc as not more required
>  * Add ecdh_helper functions for wrapping kpp async calls
> 
> This patch has been tested *only* with selftest, which is called on
> module loading. smp-tester passes all tests but the first one, which
> often times out. Same behavior is observed without this patch though.
> 
> This patch is based on https://patchwork.kernel.org/patch/9050061/
> 
> Signed-off-by: Salvatore Benedetto 
> ---
>  net/bluetooth/Makefile  |   2 +-
>  net/bluetooth/ecc.c | 816 
> 
>  net/bluetooth/ecc.h |  54 ---
>  net/bluetooth/ecdh_helper.c | 204 +++
>  net/bluetooth/ecdh_helper.h |  32 ++
>  net/bluetooth/selftest.c|   6 +-
>  net/bluetooth/smp.c |   8 +-
>  7 files changed, 244 insertions(+), 878 deletions(-)
>  delete mode 100644 net/bluetooth/ecc.c
>  delete mode 100644 net/bluetooth/ecc.h
>  create mode 100644 net/bluetooth/ecdh_helper.c
>  create mode 100644 net/bluetooth/ecdh_helper.h

I tried this together with your kpp patches and I was able to
successfully pair, so from that perspective we're fine and I have no
objections for those patches being merged.

There are a couple of things to improve with this patch however:

The first issue is that you're missing a 'select CRYPTO_ECDH' in
net/bluetooth/Kconfig. Without this you'll end up creating a kernel that
either doesn't build or a module that doesn't load.

> +#ifndef __ECDH_HELPER_H
> +#define __ECDH_HELPER_H

Please leave out these include guards for internal headers. We try to
avoid them there to force keeping the dependency chains simple. I
realize you might have copied this from smp.h (which is the only
internal header I could see having this) so that might need fixing in a
separate patch.

> +bool compute_ecdh_shared_secret(const u8 pub_a[64], const u8 priv_b[32],
> + u8 secret[32]);
> +bool generate_ecdh_key_pair(u8 public_key[64], u8 private_key[32]);

Could you try to come up with some shorter names than these since they
cause the line lengths to go past 80 chars. In fact, can't you just keep
the same names as our ecc.c was using. I don't think those names are
taken by your new kpp code?

Johan
--
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 5/8] KEYS: Provide software public key query function [ver 3]

2016-05-12 Thread Mat Martineau



On Thu, 12 May 2016, David Howells wrote:


Mat Martineau  wrote:


+   len = crypto_akcipher_maxsize(tfm);
+   info->key_size = len * 8;
+   info->max_data_size = len;
+   info->max_sig_size = len;
+   info->max_enc_size = len;
+   info->max_dec_size = len;


If len > UINT16_MAX, should UINT16_MAX be reported as the max size? Similar
question for len*8 and key_size.


key_size is 32 bits, but the other sizes are all 16 bits, so you would need a
524288-bit key to exceed their capacity.  I'm not sure that's likely anytime
soon, but should I just make all the sizes 32-bit anyway?


Given that cryto_akcipher_maxsize() returns an int and keyctl_pkey_query 
is part of the userspace API, I support bumping the sizes to 32-bit.


--
Mat Martineau
Intel OTC

--
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 v2] crypto: rsa - return raw integers for the ASN.1 parser

2016-05-12 Thread Tudor Ambarus

Return kmalloced raw integers with no other processing.
The scope is to have only one ANS.1 parser for the RSA keys.

Update the RSA software implementation so that it does
the MPI conversion on top.

Signed-off-by: Tudor Ambarus 
---
Changes from initial patch:
- remove device related variables from the generic helper
- move struct rsa_mpi_key to rsa.c; the helper now handles
raw integers.
- cosmetics on error path for rsa_get_n,e,d functions

 crypto/rsa.c  | 132 ++
 crypto/rsa_helper.c   | 111 +--
 include/crypto/internal/rsa.h |  20 +--
 3 files changed, 190 insertions(+), 73 deletions(-)

diff --git a/crypto/rsa.c b/crypto/rsa.c
index 77d737f..c181ad9 100644
--- a/crypto/rsa.c
+++ b/crypto/rsa.c
@@ -14,12 +14,24 @@
 #include 
 #include 
 #include 
+#include 
+
+struct rsa_mpi_key {
+   MPI n;
+   MPI e;
+   MPI d;
+};
+
+struct rsa_ctx {
+   struct rsa_key key;
+   struct rsa_mpi_key mpi_key;
+};
 
 /*
  * RSAEP function [RFC3447 sec 5.1.1]
  * c = m^e mod n;
  */
-static int _rsa_enc(const struct rsa_key *key, MPI c, MPI m)
+static int _rsa_enc(const struct rsa_mpi_key *key, MPI c, MPI m)
 {
/* (1) Validate 0 <= m < n */
if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
@@ -33,7 +45,7 @@ static int _rsa_enc(const struct rsa_key *key, MPI c, MPI m)
  * RSADP function [RFC3447 sec 5.1.2]
  * m = c^d mod n;
  */
-static int _rsa_dec(const struct rsa_key *key, MPI m, MPI c)
+static int _rsa_dec(const struct rsa_mpi_key *key, MPI m, MPI c)
 {
/* (1) Validate 0 <= c < n */
if (mpi_cmp_ui(c, 0) < 0 || mpi_cmp(c, key->n) >= 0)
@@ -47,7 +59,7 @@ static int _rsa_dec(const struct rsa_key *key, MPI m, MPI c)
  * RSASP1 function [RFC3447 sec 5.2.1]
  * s = m^d mod n
  */
-static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
+static int _rsa_sign(const struct rsa_mpi_key *key, MPI s, MPI m)
 {
/* (1) Validate 0 <= m < n */
if (mpi_cmp_ui(m, 0) < 0 || mpi_cmp(m, key->n) >= 0)
@@ -61,7 +73,7 @@ static int _rsa_sign(const struct rsa_key *key, MPI s, MPI m)
  * RSAVP1 function [RFC3447 sec 5.2.2]
  * m = s^e mod n;
  */
-static int _rsa_verify(const struct rsa_key *key, MPI m, MPI s)
+static int _rsa_verify(const struct rsa_mpi_key *key, MPI m, MPI s)
 {
/* (1) Validate 0 <= s < n */
if (mpi_cmp_ui(s, 0) < 0 || mpi_cmp(s, key->n) >= 0)
@@ -71,15 +83,17 @@ static int _rsa_verify(const struct rsa_key *key, MPI m, 
MPI s)
return mpi_powm(m, s, key->e, key->n);
 }
 
-static inline struct rsa_key *rsa_get_key(struct crypto_akcipher *tfm)
+static inline struct rsa_mpi_key *rsa_get_key(struct crypto_akcipher *tfm)
 {
-   return akcipher_tfm_ctx(tfm);
+   struct rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+
+   return >mpi_key;
 }
 
 static int rsa_enc(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI m, c = mpi_alloc(0);
int ret = 0;
int sign;
@@ -118,7 +132,7 @@ err_free_c:
 static int rsa_dec(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI c, m = mpi_alloc(0);
int ret = 0;
int sign;
@@ -156,7 +170,7 @@ err_free_m:
 static int rsa_sign(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI m, s = mpi_alloc(0);
int ret = 0;
int sign;
@@ -195,7 +209,7 @@ err_free_s:
 static int rsa_verify(struct akcipher_request *req)
 {
struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
-   const struct rsa_key *pkey = rsa_get_key(tfm);
+   const struct rsa_mpi_key *pkey = rsa_get_key(tfm);
MPI s, m = mpi_alloc(0);
int ret = 0;
int sign;
@@ -233,66 +247,107 @@ err_free_m:
return ret;
 }
 
-static int rsa_check_key_length(unsigned int len)
+static void rsa_free_mpi_key(struct rsa_mpi_key *key)
 {
-   switch (len) {
-   case 512:
-   case 1024:
-   case 1536:
-   case 2048:
-   case 3072:
-   case 4096:
-   return 0;
-   }
-
-   return -EINVAL;
+   mpi_free(key->d);
+   mpi_free(key->e);
+   mpi_free(key->n);
+   key->d = NULL;
+   key->e = NULL;
+   key->n = NULL;
 }
 
 static int rsa_set_pub_key(struct crypto_akcipher *tfm, const void *key,
   unsigned int keylen)
 {
-   struct rsa_key *pkey = akcipher_tfm_ctx(tfm);
+   struct rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_key

[PATCH 3/3] crypto: caam - add support for RSA algorithm

2016-05-12 Thread Tudor Ambarus

Add RSA support to caam driver.

Coauthored-by: Yashpal Dutta 

Signed-off-by: Tudor Ambarus 
---
 drivers/crypto/caam/Kconfig|  12 ++
 drivers/crypto/caam/Makefile   |   4 +
 drivers/crypto/caam/caampkc.c  | 466 +
 drivers/crypto/caam/caampkc.h  |  94 +
 drivers/crypto/caam/desc.h |   2 +
 drivers/crypto/caam/pdb.h  |  16 +-
 drivers/crypto/caam/pkc_desc.c | 138 
 7 files changed, 731 insertions(+), 1 deletion(-)
 create mode 100644 drivers/crypto/caam/caampkc.c
 create mode 100644 drivers/crypto/caam/caampkc.h
 create mode 100644 drivers/crypto/caam/pkc_desc.c

diff --git a/drivers/crypto/caam/Kconfig b/drivers/crypto/caam/Kconfig
index 5652a53..9ba 100644
--- a/drivers/crypto/caam/Kconfig
+++ b/drivers/crypto/caam/Kconfig
@@ -99,6 +99,18 @@ config CRYPTO_DEV_FSL_CAAM_AHASH_API
  To compile this as a module, choose M here: the module
  will be called caamhash.
 
+config CRYPTO_DEV_FSL_CAAM_PKC_API
+tristate "Register public key cryptography implementations with Crypto 
API"
+depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
+default y
+select CRYPTO_RSA
+help
+  Selecting this will allow SEC Public key support for RSA.
+  Supported cryptographic primitives: encryption, decryption,
+  signature and verification.
+  To compile this as a module, choose M here: the module
+  will be called caam_pkc.
+
 config CRYPTO_DEV_FSL_CAAM_RNG_API
tristate "Register caam device for hwrng API"
depends on CRYPTO_DEV_FSL_CAAM && CRYPTO_DEV_FSL_CAAM_JR
diff --git a/drivers/crypto/caam/Makefile b/drivers/crypto/caam/Makefile
index 550758a..399ad55 100644
--- a/drivers/crypto/caam/Makefile
+++ b/drivers/crypto/caam/Makefile
@@ -5,11 +5,15 @@ ifeq ($(CONFIG_CRYPTO_DEV_FSL_CAAM_DEBUG), y)
EXTRA_CFLAGS := -DDEBUG
 endif
 
+ccflags-y += -I$(srctree)/crypto
+
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM) += caam.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_JR) += caam_jr.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_CRYPTO_API) += caamalg.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_AHASH_API) += caamhash.o
 obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_RNG_API) += caamrng.o
+obj-$(CONFIG_CRYPTO_DEV_FSL_CAAM_PKC_API) += caam_pkc.o
 
 caam-objs := ctrl.o
 caam_jr-objs := jr.o key_gen.o error.o
+caam_pkc-y := caampkc.o pkc_desc.o
diff --git a/drivers/crypto/caam/caampkc.c b/drivers/crypto/caam/caampkc.c
new file mode 100644
index 000..34ffa87
--- /dev/null
+++ b/drivers/crypto/caam/caampkc.c
@@ -0,0 +1,466 @@
+/*
+ * caam - Freescale FSL CAAM support for Public Key Cryptography
+ *
+ * Copyright 2016 Freescale Semiconductor, Inc.
+ *
+ * There is no Shared Descriptor for PKC so that the Job Descriptor must carry
+ * all the desired key parameters, input and output pointers.
+ */
+#include 
+#include 
+#include "compat.h"
+#include "caampkc.h"
+#include "sg_sw_sec4.h"
+#include "regs.h"
+#include "intern.h"
+#include "jr.h"
+#include "error.h"
+
+static void rsa_io_unmap(struct device *dev, struct rsa_edesc *edesc,
+struct akcipher_request *req)
+{
+   dma_unmap_sg(dev, req->dst, edesc->dst_nents, DMA_FROM_DEVICE);
+   dma_unmap_sg(dev, req->src, edesc->src_nents, DMA_TO_DEVICE);
+}
+
+static void rsa_pub_unmap(struct device *dev, struct rsa_edesc *edesc,
+ struct akcipher_request *req)
+{
+   struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+   struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_key *key = >key;
+   struct rsa_pub_desc *hw_desc = (struct rsa_pub_desc *)edesc->hw_desc;
+
+   dma_unmap_single(dev, hw_desc->n_dma, key->n_sz, DMA_TO_DEVICE);
+   dma_unmap_single(dev, hw_desc->e_dma, key->e_sz, DMA_TO_DEVICE);
+}
+
+static void rsa_priv_f1_unmap(struct device *dev, struct rsa_edesc *edesc,
+ struct akcipher_request *req)
+{
+   struct crypto_akcipher *tfm = crypto_akcipher_reqtfm(req);
+   struct caam_rsa_ctx *ctx = akcipher_tfm_ctx(tfm);
+   struct rsa_key *key = >key;
+   struct rsa_priv_f1_desc *hw_desc =
+   (struct rsa_priv_f1_desc *)edesc->hw_desc;
+
+   dma_unmap_single(dev, hw_desc->n_dma, key->n_sz, DMA_TO_DEVICE);
+   dma_unmap_single(dev, hw_desc->d_dma, key->n_sz, DMA_TO_DEVICE);
+}
+
+static size_t skip_to_nonzero(u8 *ptr, size_t nbytes)
+{
+   size_t nr_zeros = 0;
+
+   while (!(*ptr) && nbytes) {
+   nbytes--;
+   ptr++;
+   nr_zeros++;
+   }
+
+   return nr_zeros;
+}
+
+static size_t scatterwalk_skip_zeros(struct scatter_walk *walk, size_t nbytes)
+{
+   size_t len_this_page, nr_zeros, cnt = 0;
+   u8 *vaddr, *ptr;
+
+   for (;;) {
+   nr_zeros = 0;
+   len_this_page = scatterwalk_pagelen(walk);
+
+   if (len_this_page >

[PATCH 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

2016-05-12 Thread Tudor Ambarus

This patch adds the function scatterwalk_sg_copychunks which writes
a chunk of data from a scatterwalk to another scatterwalk.
It will be used by caam driver to remove the leading zeros
for the output data of the RSA algorithm, after the computation completes.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 26 ++
 include/crypto/scatterwalk.h |  2 ++
 2 files changed, 28 insertions(+)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index ea5815c..bc3222d 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -125,6 +125,32 @@ void scatterwalk_map_and_copy(void *buf, struct 
scatterlist *sg,
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map_and_copy);
 
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes)
+{
+   for (;;) {
+   unsigned int len_this_page = scatterwalk_pagelen(dest);
+   u8 *vaddr;
+
+   if (len_this_page > nbytes)
+   len_this_page = nbytes;
+
+   vaddr = scatterwalk_map(dest);
+   scatterwalk_copychunks(vaddr, src, len_this_page, 0);
+   scatterwalk_unmap(vaddr);
+
+   scatterwalk_advance(dest, len_this_page);
+
+   if (nbytes == len_this_page)
+   break;
+
+   nbytes -= len_this_page;
+
+   scatterwalk_pagedone(dest, 0, 1);
+   }
+}
+EXPORT_SYMBOL_GPL(scatterwalk_sg_copychunks);
+
 int scatterwalk_bytes_sglen(struct scatterlist *sg, int num_bytes)
 {
int offset = 0, n = 0;
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 35f99b6..8b799c5 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -86,6 +86,8 @@ static inline void scatterwalk_unmap(void *vaddr)
 void scatterwalk_start(struct scatter_walk *walk, struct scatterlist *sg);
 void scatterwalk_copychunks(void *buf, struct scatter_walk *walk,
size_t nbytes, int out);
+void scatterwalk_sg_copychunks(struct scatter_walk *dest,
+  struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
-- 
1.8.3.1

--
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 v5 0/3] crypto: caam - add support for RSA algorithm

2016-05-12 Thread Tudor Ambarus

Depends on:
[PATCH v2] crypto: rsa - return raw integers for the ASN.1 parser

Changes from v4:
- sync with ASN.1 parser

Changes from v3:
- sync with ASN.1 parser

Changes from v2:
- sync with ASN.1 parser

Changes from initial patch:
- fix memory leaks on error path
- rename struct akcipher_alg rsa to caam_rsa

Tudor Ambarus (3):
  crypto: scatterwak - Add scatterwalk_sg_copychunks
  crypto: scatterwalk - export scatterwalk_pagedone
  crypto: caam - add support for RSA algorithm

 crypto/scatterwalk.c   |  31 ++-
 drivers/crypto/caam/Kconfig|  12 ++
 drivers/crypto/caam/Makefile   |   4 +
 drivers/crypto/caam/caampkc.c  | 466 +
 drivers/crypto/caam/caampkc.h  |  94 +
 drivers/crypto/caam/desc.h |   2 +
 drivers/crypto/caam/pdb.h  |  16 +-
 drivers/crypto/caam/pkc_desc.c | 138 
 include/crypto/scatterwalk.h   |   4 +
 9 files changed, 764 insertions(+), 3 deletions(-)
 create mode 100644 drivers/crypto/caam/caampkc.c
 create mode 100644 drivers/crypto/caam/caampkc.h
 create mode 100644 drivers/crypto/caam/pkc_desc.c

-- 
1.8.3.1

--
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 2/3] crypto: scatterwalk - export scatterwalk_pagedone

2016-05-12 Thread Tudor Ambarus

Used in caam driver. Export the symbol since the caam driver
can be built as a module.

Signed-off-by: Tudor Ambarus 
---
 crypto/scatterwalk.c | 5 +++--
 include/crypto/scatterwalk.h | 2 ++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/crypto/scatterwalk.c b/crypto/scatterwalk.c
index bc3222d..03d34f9 100644
--- a/crypto/scatterwalk.c
+++ b/crypto/scatterwalk.c
@@ -47,8 +47,8 @@ void *scatterwalk_map(struct scatter_walk *walk)
 }
 EXPORT_SYMBOL_GPL(scatterwalk_map);
 
-static void scatterwalk_pagedone(struct scatter_walk *walk, int out,
-unsigned int more)
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more)
 {
if (out) {
struct page *page;
@@ -69,6 +69,7 @@ static void scatterwalk_pagedone(struct scatter_walk *walk, 
int out,
scatterwalk_start(walk, sg_next(walk->sg));
}
 }
+EXPORT_SYMBOL_GPL(scatterwalk_pagedone);
 
 void scatterwalk_done(struct scatter_walk *walk, int out, int more)
 {
diff --git a/include/crypto/scatterwalk.h b/include/crypto/scatterwalk.h
index 8b799c5..6535a20 100644
--- a/include/crypto/scatterwalk.h
+++ b/include/crypto/scatterwalk.h
@@ -89,6 +89,8 @@ void scatterwalk_copychunks(void *buf, struct scatter_walk 
*walk,
 void scatterwalk_sg_copychunks(struct scatter_walk *dest,
   struct scatter_walk *src, size_t nbytes);
 void *scatterwalk_map(struct scatter_walk *walk);
+void scatterwalk_pagedone(struct scatter_walk *walk, int out,
+ unsigned int more);
 void scatterwalk_done(struct scatter_walk *walk, int out, int more);
 
 void scatterwalk_map_and_copy(void *buf, struct scatterlist *sg,
-- 
1.8.3.1

--
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 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

2016-05-12 Thread David Woodhouse

On Wed, 2016-05-11 at 15:17 -0700, Mat Martineau wrote:
> 
> On Wed, 11 May 2016, David Howells wrote:
> 
> > diff --git a/Documentation/security/keys.txt 
> > b/Documentation/security/keys.txt
> > index ca72b70a24b9..01c2ae28a8c0 100644
> > --- a/Documentation/security/keys.txt
> > +++ b/Documentation/security/keys.txt
> > + If the key needs to be unlocked with a password, a logon-type key that
> > + holds the password may be given as the password argument
> ...
> > + If the key must be unlocked with a password before it can be used,
> > + password_id should point to a logon-type key that holds this.
> 
> It should be noted that the password_id should be 0 if no password is to 
> be used.

Hm, I would like to properly explore the use cases for these passwords,
before any API is set in stone.

To start with, I'll insist quite strongly that we should never be
passing an encrypted key into the kernel alongside the password needed
to decrypt it. We should let userspace do that gruntwork, and pass in a
canonical DER PKCS#8 (or PKCS#1) blob. As I said before, the other way
lies madness, and requests to support all the obscure formats that keys
are stored in.

So where *might* we want a password... mostly for things like TPM and
other crypto hardware (USB tokens, HSMs). And the usage model there is
normally that the password isn't tied to the *key*, it's a password or
PIN to unlock the *device*.

So I'm not quite sure this 'password_id' makes much sense at all...
unless the idea is that you load the (encrypted) key in advance and
then request the password *later* on demand, in order to use it? Is
that something we really need to support?

-- 
David WoodhouseOpen Source Technology Centre
david.woodho...@intel.com  Intel Corporation

smime.p7s
Description: S/MIME cryptographic signature

Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3]

2016-05-12 Thread David Howells

Mat Martineau  wrote:

> > # PKCS#7 message handling
> 
> Update to PKCS#8

I guess I've typed PKCS#7 too many times :-)

David
--
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 5/8] KEYS: Provide software public key query function [ver 3]

2016-05-12 Thread David Howells

Mat Martineau  wrote:

> > +   len = crypto_akcipher_maxsize(tfm);
> > +   info->key_size = len * 8;
> > +   info->max_data_size = len;
> > +   info->max_sig_size = len;
> > +   info->max_enc_size = len;
> > +   info->max_dec_size = len;
> 
> If len > UINT16_MAX, should UINT16_MAX be reported as the max size? Similar
> question for len*8 and key_size.

key_size is 32 bits, but the other sizes are all 16 bits, so you would need a
524288-bit key to exceed their capacity.  I'm not sure that's likely anytime
soon, but should I just make all the sizes 32-bit anyway?

David
--
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: SHA1-MB algorithm broken on latest kernel

Re: SHA1-MB algorithm broken on latest kernel

SHA1-MB algorithm broken on latest kernel

RE: [PATCH v2] Bluetooth: convert smp and selftest to crypto kpp API

Re: [PATCH v6 0/3] Key-agreement Protocol Primitives (KPP) API

Re: [PATCH 3/3] crypto: caam - add support for RSA algorithm

Re: [PATCH v2] Bluetooth: convert smp and selftest to crypto kpp API

Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

[PATCH v2] crypto: rsa - return raw integers for the ASN.1 parser

[PATCH 3/3] crypto: caam - add support for RSA algorithm

[PATCH 1/3] crypto: scatterwak - Add scatterwalk_sg_copychunks

[PATCH v5 0/3] crypto: caam - add support for RSA algorithm

[PATCH 2/3] crypto: scatterwalk - export scatterwalk_pagedone

Re: [RFC PATCH 2/8] KEYS: Provide keyctls to drive the new key type ops for asymmetric keys [ver 3]

Re: [RFC PATCH 8/8] KEYS: Implement PKCS#8 RSA Private Key parser [ver 3]

Re: [RFC PATCH 5/8] KEYS: Provide software public key query function [ver 3]

16 matches

Site Navigation

Mail list logo

Footer information