date:20160413

[PATCH V3 00/29] bitops: add parity functions

2016-04-13 Thread zengzhaoxiu

From: Zhaoxiu Zeng 

When I do "grep parity -r linux", I found many parity calculations
distributed in many drivers.

This patch series does:
  1. provide generic and architecture-specific parity calculations
  2. remove drivers' local parity calculations, use bitops' parity
 functions instead
  3. replace "hweightN(x) & 1" with "parityN(x)" to improve readability,
 and improve performance on some CPUs that without popcount support

I did not use GCC's __builtin_parity* functions, based on the following reasons:
  1. I don't know where to identify which version of GCC from the beginning
 supported __builtin_parity for the architecture.
  2. For the architecture that doesn't has popcount instruction, GCC instead use
 "call __paritysi2" (__paritydi2 for 64-bits). So if use __builtin_parity, 
we must
 provide __paritysi2 and __paritydi2 functions for these architectures.
 Additionally, parity4,8,16 might be "__builtin_parity(x & mask)", but the 
"& mask"
 operation is totally unnecessary.
  3. For the architecture that has popcount instruction, we do the same things.
  4. For powerpc, sparc, and x86, we do runtime patching to use popcount 
instruction
 if the CPU support.

I have compiled successfully with x86_64_defconfig, i386_defconfig, 
pseries_defconfig
and sparc64_defconfig.

Changes to v2:
- Add constant PARITY_MAGIC (proposals by Sam Ravnborg)
- Add include/asm-generic/bitops/popc-parity.h (proposals by Chris Metcalf)
- Tile uses popc-parity.h directly
- Mips uses popc-parity.h if has usable __builtin_popcount
- Add few comments in powerpc's and sparc's parity.S
- X86, remove custom calling convention

Changes to v1:
- Add runtime patching for powerpc, sparc, and x86
- Avr32 use grenric parity too
- Fix error in ssfdc's patch, and add commit message
- Don't change the original code composition of drivers/iio/gyro/adxrs450.c
- Directly assignement to phy_cap.parity in drivers/scsi/isci/phy.c

Regards,

=== diffstat ===

Zhaoxiu Zeng (29):
  bitops: add parity functions
  Include generic parity.h in some architectures' bitops.h
  Add alpha-specific parity functions
  Add blackfin-specific parity functions
  Add ia64-specific parity functions
  Tile and MIPS (if has usable __builtin_popcount) use popcount parity
functions
  Add powerpc-specific parity functions
  Add sparc-specific parity functions
  Add x86-specific parity functions
  sunrpc: use parity8
  mips: use parity functions in cerr-sb1.c
  bch: use parity32
  media: use parity8 in vivid-vbi-gen.c
  media: use parity functions in saa7115
  input: use parity32 in grip_mp
  input: use parity64 in sidewinder
  input: use parity16 in ams_delta_serio
  scsi: use parity32 in isci's phy
  mtd: use parity16 in ssfdc
  mtd: use parity functions in inftlcore
  crypto: use parity functions in qat_hal
  mtd: use parity16 in sm_ftl
  ethernet: use parity8 in sun/niu.c
  input: use parity8 in pcips2
  input: use parity8 in saps2
  iio: use parity32 in adxrs450
  serial: use parity32 in max3100
  input: use parity8 in elantech
  ethernet: use parity8 in broadcom/tg3.c

 arch/alpha/include/asm/bitops.h  |  27 +
 arch/arc/include/asm/bitops.h|   1 +
 arch/arm/include/asm/bitops.h|   1 +
 arch/arm64/include/asm/bitops.h  |   1 +
 arch/avr32/include/asm/bitops.h  |   1 +
 arch/blackfin/include/asm/bitops.h   |  31 ++
 arch/c6x/include/asm/bitops.h|   1 +
 arch/cris/include/asm/bitops.h   |   1 +
 arch/frv/include/asm/bitops.h|   1 +
 arch/h8300/include/asm/bitops.h  |   1 +
 arch/hexagon/include/asm/bitops.h|   1 +
 arch/ia64/include/asm/bitops.h   |  31 ++
 arch/m32r/include/asm/bitops.h   |   1 +
 arch/m68k/include/asm/bitops.h   |   1 +
 arch/metag/include/asm/bitops.h  |   1 +
 arch/mips/include/asm/bitops.h   |   7 ++
 arch/mips/mm/cerr-sb1.c  |  67 -
 arch/mn10300/include/asm/bitops.h|   1 +
 arch/openrisc/include/asm/bitops.h   |   1 +
 arch/parisc/include/asm/bitops.h |   1 +
 arch/powerpc/include/asm/bitops.h|  11 +++
 arch/powerpc/lib/Makefile|   2 +-
 arch/powerpc/lib/parity_64.S | 142 +++
 arch/powerpc/lib/ppc_ksyms.c |   5 +
 arch/s390/include/asm/bitops.h   |   1 +
 arch/sh/include/asm/bitops.h |   1 +
 arch/sparc/include/asm/bitops_32.h   |   1 +
 arch/sparc/include/asm/bitops_64.h   |  18 
 arch/sparc/kernel/sparc_ksyms_64.c   |   6 ++
 arch/sparc/lib/Makefile  |   2 +-
 arch/sparc/lib/parity.S  | 128 
 arch/tile/include/asm/bitops.h   |   2 +
 arch/x86/include/asm/arch_hweight.h  |   5

[PATCH V3 21/29] crypto: use parity functions in qat_hal

2016-04-13 Thread zengzhaoxiu

From: Zhaoxiu Zeng 

Signed-off-by: Zhaoxiu Zeng 
---
 drivers/crypto/qat/qat_common/qat_hal.c | 32 ++--
 1 file changed, 10 insertions(+), 22 deletions(-)

diff --git a/drivers/crypto/qat/qat_common/qat_hal.c 
b/drivers/crypto/qat/qat_common/qat_hal.c
index 1e480f1..318558f 100644
--- a/drivers/crypto/qat/qat_common/qat_hal.c
+++ b/drivers/crypto/qat/qat_common/qat_hal.c
@@ -546,17 +546,6 @@ static void qat_hal_disable_ctx(struct 
icp_qat_fw_loader_handle *handle,
qat_hal_wr_ae_csr(handle, ae, CTX_ENABLES, ctx);
 }
 
-static uint64_t qat_hal_parity_64bit(uint64_t word)
-{
-   word ^= word >> 1;
-   word ^= word >> 2;
-   word ^= word >> 4;
-   word ^= word >> 8;
-   word ^= word >> 16;
-   word ^= word >> 32;
-   return word & 1;
-}
-
 static uint64_t qat_hal_set_uword_ecc(uint64_t uword)
 {
uint64_t bit0_mask = 0xff87fffULL, bit1_mask = 0x1f801ff801fULL,
@@ -566,13 +555,13 @@ static uint64_t qat_hal_set_uword_ecc(uint64_t uword)
 
/* clear the ecc bits */
uword &= ~(0x7fULL << 0x2C);
-   uword |= qat_hal_parity_64bit(bit0_mask & uword) << 0x2C;
-   uword |= qat_hal_parity_64bit(bit1_mask & uword) << 0x2D;
-   uword |= qat_hal_parity_64bit(bit2_mask & uword) << 0x2E;
-   uword |= qat_hal_parity_64bit(bit3_mask & uword) << 0x2F;
-   uword |= qat_hal_parity_64bit(bit4_mask & uword) << 0x30;
-   uword |= qat_hal_parity_64bit(bit5_mask & uword) << 0x31;
-   uword |= qat_hal_parity_64bit(bit6_mask & uword) << 0x32;
+   uword |= (uint64_t)parity64(bit0_mask & uword) << 0x2C;
+   uword |= (uint64_t)parity64(bit1_mask & uword) << 0x2D;
+   uword |= (uint64_t)parity64(bit2_mask & uword) << 0x2E;
+   uword |= (uint64_t)parity64(bit3_mask & uword) << 0x2F;
+   uword |= (uint64_t)parity64(bit4_mask & uword) << 0x30;
+   uword |= (uint64_t)parity64(bit5_mask & uword) << 0x31;
+   uword |= (uint64_t)parity64(bit6_mask & uword) << 0x32;
return uword;
 }
 
@@ -853,15 +842,14 @@ void qat_hal_wr_umem(struct icp_qat_fw_loader_handle 
*handle,
uaddr |= UA_ECS;
qat_hal_wr_ae_csr(handle, ae, USTORE_ADDRESS, uaddr);
for (i = 0; i < words_num; i++) {
-   unsigned int uwrd_lo, uwrd_hi, tmp;
+   unsigned int uwrd_lo, uwrd_hi;
 
uwrd_lo = ((data[i] & 0xfff) << 4) | (0x3 << 18) |
  ((data[i] & 0xff00) << 2) |
  (0x3 << 8) | (data[i] & 0xff);
uwrd_hi = (0xf << 4) | ((data[i] & 0xf000) >> 28);
-   uwrd_hi |= (hweight32(data[i] & 0x) & 0x1) << 8;
-   tmp = ((data[i] >> 0x10) & 0x);
-   uwrd_hi |= (hweight32(tmp) & 0x1) << 9;
+   uwrd_hi |= parity16(data[i]) << 8;
+   uwrd_hi |= parity16(data[i] >> 16) << 9;
qat_hal_wr_ae_csr(handle, ae, USTORE_DATA_LOWER, uwrd_lo);
qat_hal_wr_ae_csr(handle, ae, USTORE_DATA_UPPER, uwrd_hi);
}
-- 
2.5.0


--
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/3] crypto: af_alg - add TLS type encryption

2016-04-13 Thread Tadeusz Struk

Hi Fridolin,
On 04/12/2016 04:13 AM, Fridolin Pokorny wrote:
> we were experimenting with this. We have a prove of concept of a kernel
> TLS type socket, so called AF_KTLS, which is based on Dave Watson's
> RFC5288 patch. It handles both TLS and DTLS, unfortunately it is not
> ready now to be proposed here. There are still issues which should be
> solved (but mostly user space API design) [1]. If you are interested, we
> could combine efforts.
> 
> Regards,
> Fridolin Pokorny
> 
> [1] https://github.com/fridex/af_ktls

I had a quick look and it looks like is limited only to gcm(aes). 
I would be more interested to have a generic interface that could do generic 
algorithm
suits like aes-cbc-hmac-sha1 also.
This also seems to work in a synchronous (send one and wait) mode, which is a 
not good
solution for HW accelerators, which I'm trying to enable.
Thanks,
-- 
TS
--
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: sha1-mb - use corrcet pointer while completing jobs

2016-04-13 Thread Tim Chen

On Tue, 2016-04-12 at 09:45 +, Xiaodong Liu wrote:
> In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is
> used
> when check and complete other jobs. If the memory of first completed
> req
> is freed, while still completing other jobs in the func, kernel will
> crash since NULL pointer is assigned to RIP.


> Signed-off-by: Xiaodong Liu 
> ---
>  arch/x86/crypto/sha-mb/sha1_mb.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/x86/crypto/sha-mb/sha1_mb.c b/arch/x86/crypto/sha-
> mb/sha1_mb.c
> index a8a0224..081255c 100644
> --- a/arch/x86/crypto/sha-mb/sha1_mb.c
> +++ b/arch/x86/crypto/sha-mb/sha1_mb.c
> @@ -453,10 +453,10 @@ static int sha_complete_job(struct
> mcryptd_hash_request_ctx *rctx,
>  
>   req = cast_mcryptd_ctx_to_req(req_ctx);
>   if (irqs_disabled())
> - rctx->complete(>base, ret);
> + req_ctx->complete(>base, ret);
>   else {
>   local_bh_disable();
> - rctx->complete(>base, ret);
> + req_ctx->complete(>base, ret);
>   local_bh_enable();
>   }


Agreed.  Should use req_ctx which is the ctx for the
next job that have been completed in the lanes
instead of the first completed job rctx, whose 
completion could have been called and released.

Should be propagated back to stable release.

Acked-by: Tim Chen 

Tim

> 

>   }
--
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: ccp - Prevent information leakage on export

2016-04-13 Thread Tom Lendacky

Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.

Cc:  # 3.14.x-
Reported-by: Ben Hutchings 
Signed-off-by: Tom Lendacky 
---
 drivers/crypto/ccp/ccp-crypto-aes-cmac.c |3 +++
 drivers/crypto/ccp/ccp-crypto-sha.c  |3 +++
 2 files changed, 6 insertions(+)

diff --git a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c 
b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
index 3d9acc5..60fc0fa 100644
--- a/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
+++ b/drivers/crypto/ccp/ccp-crypto-aes-cmac.c
@@ -225,6 +225,9 @@ static int ccp_aes_cmac_export(struct ahash_request *req, 
void *out)
struct ccp_aes_cmac_req_ctx *rctx = ahash_request_ctx(req);
struct ccp_aes_cmac_exp_ctx state;
 
+   /* Don't let anything leak to 'out' */
+   memset(, 0, sizeof(state));
+
state.null_msg = rctx->null_msg;
memcpy(state.iv, rctx->iv, sizeof(state.iv));
state.buf_count = rctx->buf_count;
diff --git a/drivers/crypto/ccp/ccp-crypto-sha.c 
b/drivers/crypto/ccp/ccp-crypto-sha.c
index b5ad728..8f36af6 100644
--- a/drivers/crypto/ccp/ccp-crypto-sha.c
+++ b/drivers/crypto/ccp/ccp-crypto-sha.c
@@ -212,6 +212,9 @@ static int ccp_sha_export(struct ahash_request *req, void 
*out)
struct ccp_sha_req_ctx *rctx = ahash_request_ctx(req);
struct ccp_sha_exp_ctx state;
 
+   /* Don't let anything leak to 'out' */
+   memset(, 0, sizeof(state));
+
state.type = rctx->type;
state.msg_bits = rctx->msg_bits;
state.first = rctx->first;

--
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 v4 0/2] Add Hisilicon Random Number Generator(RNG) support

2016-04-13 Thread Kefeng Wang

Changes since v3:
- Compatible name "hisilicon,hip04-rng" and  "hisilicon,hip05-rng" are used,
  suggested by Robe Herring
- Add reviewed-by from Mathieu Poirier

Changes since v2:
- Remove unused RNG_RELOAD_ERR.
- Add comment of seed choice in hisi_rng_init
- Add head inculde linux/random.h for get_random_bytes()

Changes since v1:
- Rename compatible name from "hisilicon,hisi-rng" to "hisilicon,rng"

Kefeng Wang (2):
  dt/bindings: Add bindings for hisilicon random number generator
  hwrng: hisi: Add support for Hisilicon SoC RNG

 Documentation/devicetree/bindings/rng/hisi-rng.txt |  12 ++
 drivers/char/hw_random/Kconfig |  13 +++
 drivers/char/hw_random/Makefile|   1 +
 drivers/char/hw_random/hisi-rng.c  | 126 +
 4 files changed, 152 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/hisi-rng.txt
 create mode 100644 drivers/char/hw_random/hisi-rng.c

-- 
1.7.12.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

[PATCH v4 2/2] hwrng: hisi: Add support for Hisilicon SoC RNG

2016-04-13 Thread Kefeng Wang

This adds the Hisilicon Random Number Generator(RNG) support,
which is found in Hip04 and Hip05 soc.

Reviewed-by: Mathieu Poirier 
Signed-off-by: Kefeng Wang 
---
 drivers/char/hw_random/Kconfig|  13 
 drivers/char/hw_random/Makefile   |   1 +
 drivers/char/hw_random/hisi-rng.c | 126 ++
 3 files changed, 140 insertions(+)
 create mode 100644 drivers/char/hw_random/hisi-rng.c

diff --git a/drivers/char/hw_random/Kconfig b/drivers/char/hw_random/Kconfig
index 67ee8b0..088b1bf 100644
--- a/drivers/char/hw_random/Kconfig
+++ b/drivers/char/hw_random/Kconfig
@@ -333,6 +333,19 @@ config HW_RANDOM_TPM
 
  If unsure, say Y.
 
+config HW_RANDOM_HISI
+   tristate "Hisilicon Random Number Generator support"
+   depends on HW_RANDOM && ARCH_HISI
+   default HW_RANDOM
+   ---help---
+ This driver provides kernel-side support for the Random Number
+ Generator hardware found on Hisilicon Hip04 and Hip05 SoC.
+
+ To compile this driver as a module, choose M here: the
+ module will be called hisi-rng.
+
+ If unsure, say Y.
+
 config HW_RANDOM_MSM
tristate "Qualcomm SoCs Random Number Generator support"
depends on HW_RANDOM && ARCH_QCOM
diff --git a/drivers/char/hw_random/Makefile b/drivers/char/hw_random/Makefile
index f5a6fa7..e09305b 100644
--- a/drivers/char/hw_random/Makefile
+++ b/drivers/char/hw_random/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_HW_RANDOM_PPC4XX) += ppc4xx-rng.o
 obj-$(CONFIG_HW_RANDOM_PSERIES) += pseries-rng.o
 obj-$(CONFIG_HW_RANDOM_POWERNV) += powernv-rng.o
 obj-$(CONFIG_HW_RANDOM_EXYNOS) += exynos-rng.o
+obj-$(CONFIG_HW_RANDOM_HISI)   += hisi-rng.o
 obj-$(CONFIG_HW_RANDOM_TPM) += tpm-rng.o
 obj-$(CONFIG_HW_RANDOM_BCM2835) += bcm2835-rng.o
 obj-$(CONFIG_HW_RANDOM_IPROC_RNG200) += iproc-rng200.o
diff --git a/drivers/char/hw_random/hisi-rng.c 
b/drivers/char/hw_random/hisi-rng.c
new file mode 100644
index 000..40d9657
--- /dev/null
+++ b/drivers/char/hw_random/hisi-rng.c
@@ -0,0 +1,126 @@
+/*
+ * Copyright (C) 2016 HiSilicon Co., Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define RNG_SEED   0x0
+#define RNG_CTRL   0x4
+  #define RNG_SEED_SEL BIT(2)
+  #define RNG_RING_EN  BIT(1)
+  #define RNG_EN   BIT(0)
+#define RNG_RAN_NUM0x10
+#define RNG_PHY_SEED   0x14
+
+#define to_hisi_rng(p) container_of(p, struct hisi_rng, rng)
+
+static int seed_sel;
+module_param(seed_sel, int, S_IRUGO);
+MODULE_PARM_DESC(seed_sel, "Auto reload seed. 0, use LFSR(default); 1, use 
ring oscillator.");
+
+struct hisi_rng {
+   void __iomem *base;
+   struct hwrng rng;
+};
+
+static int hisi_rng_init(struct hwrng *rng)
+{
+   struct hisi_rng *hrng = to_hisi_rng(rng);
+   int val = RNG_EN;
+   u32 seed;
+
+   /* get a random number as initial seed */
+   get_random_bytes(, sizeof(seed));
+
+   writel_relaxed(seed, hrng->base + RNG_SEED);
+
+   /**
+* The seed is reload periodically, there are two choice
+* of seeds, default seed using the value from LFSR, or
+* will use seed generated by ring oscillator.
+*/
+   if (seed_sel == 1)
+   val |= RNG_RING_EN | RNG_SEED_SEL;
+
+   writel_relaxed(val, hrng->base + RNG_CTRL);
+   return 0;
+}
+
+static void hisi_rng_cleanup(struct hwrng *rng)
+{
+   struct hisi_rng *hrng = to_hisi_rng(rng);
+
+   writel_relaxed(0, hrng->base + RNG_CTRL);
+}
+
+static int hisi_rng_read(struct hwrng *rng, void *buf, size_t max, bool wait)
+{
+   struct hisi_rng *hrng = to_hisi_rng(rng);
+   u32 *data = buf;
+
+   *data = readl_relaxed(hrng->base + RNG_RAN_NUM);
+   return 4;
+}
+
+static int hisi_rng_probe(struct platform_device *pdev)
+{
+   struct hisi_rng *rng;
+   struct resource *res;
+   int ret;
+
+   rng = devm_kzalloc(>dev, sizeof(*rng), GFP_KERNEL);
+   if (!rng)
+   return -ENOMEM;
+
+   platform_set_drvdata(pdev, rng);
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   rng->base = devm_ioremap_resource(>dev, res);
+   if (IS_ERR(rng->base))
+   return PTR_ERR(rng->base);
+
+   rng->rng.name = pdev->name;
+   rng->rng.init = hisi_rng_init;
+   rng->rng.cleanup = hisi_rng_cleanup;
+   rng->rng.read = hisi_rng_read;
+
+   ret = devm_hwrng_register(>dev, >rng);
+   if (ret) {
+   dev_err(>dev, "failed to register hwrng\n");
+   return ret;
+   }
+
+   return 0;
+}
+
+static const struct of_device_id hisi_rng_dt_ids[] = {
+   { .compatible = "hisilicon,hip04-rng" },
+   { .compatible =

[PATCH v4 1/2] dt/bindings: Add bindings for hisilicon random number generator

2016-04-13 Thread Kefeng Wang

Document the devicetree bindings for the random number generator found
on Hisilicon Hip04 and Hip05 soc.

Signed-off-by: Kefeng Wang 
---
 Documentation/devicetree/bindings/rng/hisi-rng.txt | 12 
 1 file changed, 12 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/rng/hisi-rng.txt

diff --git a/Documentation/devicetree/bindings/rng/hisi-rng.txt 
b/Documentation/devicetree/bindings/rng/hisi-rng.txt
new file mode 100644
index 000..d04d55a
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/hisi-rng.txt
@@ -0,0 +1,12 @@
+Hisilicon Random Number Generator
+
+Required properties:
+- compatible : Should be "hisilicon,hip04-rng" or "hisilicon,hip05-rng"
+- reg : Offset and length of the register set of this block
+
+Example:
+
+rng@d101 {
+   compatible = "hisilicon,hip05-rng";
+   reg = <0xd101 0x100>;
+};
-- 
1.7.12.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

Re: [PATCH 2/2] crypto: kpp - Add DH software implementation

2016-04-13 Thread Stephan Mueller

Am Mittwoch, 13. April 2016, 09:07:38 schrieb Benedetto, Salvatore:

Hi Salvatore,
> 
> I don't see any particular benefit in replacing this check with a lower
> boundary check only. Values other than those listed are very unlikely.
> Anyway, if you feel so strong about it and other people think the same I'm
> OK with either check :-) Either case shouldn't harm.

The kernel is not supposed to policy user decisions. It is only there to 
perform operations. It is allowed to enforce policies to cover known 
weaknesses though (hence the check for the lower boundary).

So, if a user wants to use 2040 bit DH keys, what reason has the kernel to 
object?

Note, with the advancements of quantum computers is may be likely that we all 
want to use very large keys for asymmetric ciphers in the not too distant 
future.

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 2/2] crypto: kpp - Add DH software implementation

2016-04-13 Thread Benedetto, Salvatore

> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org [mailto:linux-crypto-
> ow...@vger.kernel.org] On Behalf Of Stephan Mueller
> Sent: Tuesday, April 12, 2016 2:21 PM
> To: Benedetto, Salvatore 
> Cc: herb...@gondor.apana.org.au; linux-crypto@vger.kernel.org
> Subject: Re: [PATCH 2/2] crypto: kpp - Add DH software implementation
> 
> > >
> > > >  include/crypto/dh.h |  23 ++
> > > >  6 files changed, 631 insertions(+)  create mode 100644
> > > > crypto/dh.c  create mode 100644 include/crypto/dh.h
> > > >
> > > > +
> > > > +static int dh_check_params_length(unsigned int p_len) {
> > > > +   switch (p_len) {
> > > > +   case 1536:
> > > > +   case 2048:
> > > > +   case 3072:
> > > > +   case 4096:
> > > > +   case 6144:
> > > > +   case 8192:
> > > > +   return 0;
> > >
> > > Does the math require this check?
> > >
> > > Wouldn't it be better to implement limits to the low side (i.e.
> > > p_len <
> > > 1536) and then add a real limit due to the implementation (e.g. it
> > > must be multiple of full bytes)?
> >
> > The math itself does not require any check that I'm aware of.
> > As for the real limit, I think we have to add that as an hardware that
> > is only capable of handling up to 4096 bytes, should fall back to the
> > software implementation if a bigger param is used.
> 
> Then why not leave that check to the respective HW implementation and
> provide support for all parameters in software? I.e. simply replace this check
> with a lower boundary check only?
> 

I don't see any particular benefit in replacing this check with a lower boundary
check only. Values other than those listed are very unlikely.
Anyway, if you feel so strong about it and other people think the same I'm
OK with either check :-) Either case shouldn't harm.

Thanks,
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 v2 1/2] dt/bindings: Add bindings for hisilicon random number generator

2016-04-13 Thread Kefeng Wang



On 2016/4/12 21:54, Rob Herring wrote:
> On Mon, Apr 11, 2016 at 8:16 PM, Kefeng Wang  
> wrote:
>>
>>
>> On 2016/4/11 22:43, Rob Herring wrote:
>>> On Thu, Apr 07, 2016 at 04:23:16PM +0800, Kefeng Wang wrote:
 Document the devicetree bindings for the random number generator found
 on Hisilicon Hip04 and Hip05 soc.

 Signed-off-by: Kefeng Wang 
 ---
  Documentation/devicetree/bindings/rng/hisi-rng.txt | 12 
  1 file changed, 12 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/rng/hisi-rng.txt

 diff --git a/Documentation/devicetree/bindings/rng/hisi-rng.txt 
 b/Documentation/devicetree/bindings/rng/hisi-rng.txt
 new file mode 100644
 index 000..72efcc1
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/rng/hisi-rng.txt
 @@ -0,0 +1,12 @@
 +Hisilicon Random Number Generator
 +
 +Required properties:
 +- compatible : Should be "hisilicon,rng"
 +- reg : Offset and length of the register set of this block
 +
 +Example:
 +
 +rng@d101 {
 +compatible = "hisilicon,rng";
>>>
>>> This still needs SoC specific compatible strings.
>>
>> It is used by Hip04/Hip05 at lease, but for new SoC, like Hip06, it maybe 
>> different,
>> using single Soc prefix is not proper, how about hisilicon,rng-v1, or add 
>> two compatible
>> hisilicon,hip04-rng and hisilicon,hip05-rng? What's your option?
> 
> It is perfectly fine to include hisilicon,hip04-rng string for hip05
> and later if the block is the same. You should still have both strings
> (the original and current SoC) in case there is some issue or
> difference found.
> 
> Unless there is a real IP version defined, you should avoid made up
> version numbers.
> 

Ok, will add both of them in v4, thanks.


> Rob
> 
> .
> 

--
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 V3 00/29] bitops: add parity functions

[PATCH V3 21/29] crypto: use parity functions in qat_hal

Re: [PATCH 0/3] crypto: af_alg - add TLS type encryption

Re: [PATCH] crypto: sha1-mb - use corrcet pointer while completing jobs

[PATCH] crypto: ccp - Prevent information leakage on export

[PATCH v4 0/2] Add Hisilicon Random Number Generator(RNG) support

[PATCH v4 2/2] hwrng: hisi: Add support for Hisilicon SoC RNG

[PATCH v4 1/2] dt/bindings: Add bindings for hisilicon random number generator

Re: [PATCH 2/2] crypto: kpp - Add DH software implementation

RE: [PATCH 2/2] crypto: kpp - Add DH software implementation

Re: [PATCH v2 1/2] dt/bindings: Add bindings for hisilicon random number generator

11 matches

Site Navigation

Mail list logo

Footer information