* crypto: gcm - Filter out async ghash if necessary
From: Herbert Xu @ 2016-06-15 14:27 UTC (permalink / raw)
To: Linux Crypto Mailing List
As it is if you ask for a sync gcm you may actually end up with
an async one because it does not filter out async implementations
of ghash.
This patch fixes this by adding the necessary filter when looking
for ghash.
Cc: stable@vger.kernel.org
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
diff --git a/crypto/gcm.c b/crypto/gcm.c
index bec329b..917b8fb 100644
--- a/crypto/gcm.c
+++ b/crypto/gcm.c
@@ -639,7 +639,9 @@ static int crypto_gcm_create_common(struct crypto_template *tmpl,
ghash_alg = crypto_find_alg(ghash_name, &crypto_ahash_type,
CRYPTO_ALG_TYPE_HASH,
- CRYPTO_ALG_TYPE_AHASH_MASK);
+ CRYPTO_ALG_TYPE_AHASH_MASK |
+ crypto_requires_sync(algt->type,
+ algt->mask));
if (IS_ERR(ghash_alg))
return PTR_ERR(ghash_alg);
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply related
* Re: padata - is serial actually serial?
From: Gary R Hook @ 2016-06-15 13:53 UTC (permalink / raw)
To: Steffen Klassert, Jason A. Donenfeld; +Cc: linux-crypto, Netdev
In-Reply-To: <20160615115203.GB7698@gauss.secunet.com>
On 06/15/2016 06:52 AM, Steffen Klassert wrote:
> Hi Jason.
>
> On Tue, Jun 14, 2016 at 11:00:54PM +0200, Jason A. Donenfeld wrote:
>> Hi Steffen & Folks,
>>
>> I submit a job to padata_do_parallel(). When the parallel() function
>> triggers, I do some things, and then call padata_do_serial(). Finally
>> the serial() function triggers, where I complete the job (check a
>> nonce, etc).
>>
>> The padata API is very appealing because not only does it allow for
>> parallel computation, but it claims that the serial() functions will
>> execute in the order that jobs were originally submitted to
>> padata_do_parallel().
>>
>> Unfortunately, in practice, I'm pretty sure I'm seeing deviations from
>> this. When I submit tons and tons of tasks at rapid speed to
>> padata_do_parallel(), it seems like the serial() function isn't being
>> called in the exactly the same order that tasks were submitted to
>> padata_do_parallel().
>>
>> Is this known (expected) behavior? Or have I stumbled upon a potential
>> bug that's worthwhile for me to investigate more?
>
> It should return in the same order as the job were submitted,
> given that the submitting cpu and the callback cpu are fixed
> for all the jobs you want to preserve the order. If you submit
> jobs from more than one cpu, we can not know in which order
> they are enqueued. The cpu that gets the lock as the first
> has its job in front.
Isn't there an element of indeterminacy at the application thread level
(i.e. user space) too? We don't know how the jobs are being submitted, but
unless that is being handled by a single thread in a single process, I
think all bets are off with respect to ordering.
Then again, perhaps I'm not grokking the details here.
> Same if you use more than one callback cpu
> we can't know in which order they are dequeued, because the
> serial workers are scheduled independent on each cpu.
^ permalink raw reply
* Re: padata - is serial actually serial?
From: Steffen Klassert @ 2016-06-15 11:52 UTC (permalink / raw)
To: Jason A. Donenfeld; +Cc: linux-crypto, Netdev
In-Reply-To: <CAHmME9qnufO90qF7v9bVb7L+6KQA=kaZ=BML2sRwzbQHtFLJGA@mail.gmail.com>
Hi Jason.
On Tue, Jun 14, 2016 at 11:00:54PM +0200, Jason A. Donenfeld wrote:
> Hi Steffen & Folks,
>
> I submit a job to padata_do_parallel(). When the parallel() function
> triggers, I do some things, and then call padata_do_serial(). Finally
> the serial() function triggers, where I complete the job (check a
> nonce, etc).
>
> The padata API is very appealing because not only does it allow for
> parallel computation, but it claims that the serial() functions will
> execute in the order that jobs were originally submitted to
> padata_do_parallel().
>
> Unfortunately, in practice, I'm pretty sure I'm seeing deviations from
> this. When I submit tons and tons of tasks at rapid speed to
> padata_do_parallel(), it seems like the serial() function isn't being
> called in the exactly the same order that tasks were submitted to
> padata_do_parallel().
>
> Is this known (expected) behavior? Or have I stumbled upon a potential
> bug that's worthwhile for me to investigate more?
It should return in the same order as the job were submitted,
given that the submitting cpu and the callback cpu are fixed
for all the jobs you want to preserve the order. If you submit
jobs from more than one cpu, we can not know in which order
they are enqueued. The cpu that gets the lock as the first
has its job in front. Same if you use more than one callback cpu
we can't know in which order they are dequeued, because the
serial workers are scheduled independent on each cpu.
I use it in crypto/pcrypt.c and I never had problems.
^ permalink raw reply
* Re: [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Stephan Mueller @ 2016-06-15 11:42 UTC (permalink / raw)
To: Raveendra Padasalagi
Cc: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik
In-Reply-To: <1465983719-8313-2-git-send-email-raveendra.padasalagi@broadcom.com>
Am Mittwoch, 15. Juni 2016, 15:11:58 schrieb Raveendra Padasalagi:
Hi Raveendra,
> From: Jeff Garzik <jeff@garzik.org>
>
> This patch adds the implementation of SHA3 algorithm
> in software and it's based on original implementation
> pushed in patch https://lwn.net/Articles/518415/ with
> additional changes to match the padding rules specified
> in SHA-3 specification.
>
> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
> ---
> crypto/Kconfig | 10 ++
> crypto/Makefile | 1 +
> crypto/sha3_generic.c | 296
> ++++++++++++++++++++++++++++++++++++++++++++++++++ include/crypto/sha3.h |
> 29 +++++
> 4 files changed, 336 insertions(+)
> create mode 100644 crypto/sha3_generic.c
> create mode 100644 include/crypto/sha3.h
>
> diff --git a/crypto/Kconfig b/crypto/Kconfig
> index 1d33beb..83ee8cb 100644
> --- a/crypto/Kconfig
> +++ b/crypto/Kconfig
> @@ -750,6 +750,16 @@ config CRYPTO_SHA512_SPARC64
> SHA-512 secure hash standard (DFIPS 180-2) implemented
> using sparc64 crypto instructions, when available.
>
> +config CRYPTO_SHA3
> + tristate "SHA3 digest algorithm"
> + select CRYPTO_HASH
> + help
> + SHA-3 secure hash standard (DFIPS 202). It's based on
Typo DFIPS?
> + cryptographic sponge function family called Keccak.
> +
> + References:
> + http://keccak.noekeon.org/
> +
> config CRYPTO_TGR192
> tristate "Tiger digest algorithms"
> select CRYPTO_HASH
> diff --git a/crypto/Makefile b/crypto/Makefile
> index 4f4ef7e..0b82c47 100644
> --- a/crypto/Makefile
> +++ b/crypto/Makefile
> @@ -61,6 +61,7 @@ obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
> obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
> obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
> obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
> +obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
> obj-$(CONFIG_CRYPTO_WP512) += wp512.o
> obj-$(CONFIG_CRYPTO_TGR192) += tgr192.o
> obj-$(CONFIG_CRYPTO_GF128MUL) += gf128mul.o
> diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
> new file mode 100644
> index 0000000..162dfc3
> --- /dev/null
> +++ b/crypto/sha3_generic.c
> @@ -0,0 +1,296 @@
> +/*
> + * Cryptographic API.
> + *
> + * SHA-3, as specified in
> + * http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
> + *
> + * SHA-3 code by Jeff Garzik <jeff@garzik.org>
> + *
> + * This program is free software; you can redistribute it and/or modify it
> + * under the terms of the GNU General Public License as published by the
> Free + * Software Foundation; either version 2 of the License, or (at your
> option)• + * any later version.
> + *
> + */
> +#include <crypto/internal/hash.h>
> +#include <linux/init.h>
> +#include <linux/module.h>
> +#include <linux/types.h>
> +#include <crypto/sha3.h>
> +#include <asm/byteorder.h>
> +
> +#define KECCAK_ROUNDS 24
> +
> +#define ROTL64(x, y) (((x) << (y)) | ((x) >> (64 - (y))))
> +
> +static const u64 keccakf_rndc[24] = {
> + 0x0000000000000001, 0x0000000000008082, 0x800000000000808a,
> + 0x8000000080008000, 0x000000000000808b, 0x0000000080000001,
> + 0x8000000080008081, 0x8000000000008009, 0x000000000000008a,
> + 0x0000000000000088, 0x0000000080008009, 0x000000008000000a,
> + 0x000000008000808b, 0x800000000000008b, 0x8000000000008089,
> + 0x8000000000008003, 0x8000000000008002, 0x8000000000000080,
> + 0x000000000000800a, 0x800000008000000a, 0x8000000080008081,
> + 0x8000000000008080, 0x0000000080000001, 0x8000000080008008
> +};
> +
> +static const int keccakf_rotc[24] = {
> + 1, 3, 6, 10, 15, 21, 28, 36, 45, 55, 2, 14,
> + 27, 41, 56, 8, 25, 43, 62, 18, 39, 61, 20, 44
> +};
> +
> +static const int keccakf_piln[24] = {
> + 10, 7, 11, 17, 18, 3, 5, 16, 8, 21, 24, 4,
> + 15, 23, 19, 13, 12, 2, 20, 14, 22, 9, 6, 1
> +};
> +
> +/* update the state with given number of rounds */
> +
> +static void keccakf(u64 st[25])
> +{
> + int i, j, round;
> + u64 t, bc[5];
> +
> + for (round = 0; round < KECCAK_ROUNDS; round++) {
> +
> + /* Theta */
> + for (i = 0; i < 5; i++)
> + bc[i] = st[i] ^ st[i + 5] ^ st[i + 10] ^ st[i + 15]
> + ^ st[i + 20];
> +
> + for (i = 0; i < 5; i++) {
> + t = bc[(i + 4) % 5] ^ ROTL64(bc[(i + 1) % 5], 1);
> + for (j = 0; j < 25; j += 5)
> + st[j + i] ^= t;
> + }
> +
> + /* Rho Pi */
> + t = st[1];
> + for (i = 0; i < 24; i++) {
> + j = keccakf_piln[i];
> + bc[0] = st[j];
> + st[j] = ROTL64(t, keccakf_rotc[i]);
> + t = bc[0];
> + }
> +
> + /* Chi */
> + for (j = 0; j < 25; j += 5) {
> + for (i = 0; i < 5; i++)
> + bc[i] = st[j + i];
> + for (i = 0; i < 5; i++)
> + st[j + i] ^= (~bc[(i + 1) % 5]) &
> + bc[(i + 2) % 5];
> + }
> +
> + /* Iota */
> + st[0] ^= keccakf_rndc[round];
> + }
> +}
> +
> +static void sha3_init(struct sha3_state *sctx, unsigned int digest_sz)
> +{
> + memset(sctx, 0, sizeof(*sctx));
> + sctx->md_len = digest_sz;
> + sctx->rsiz = 200 - 2 * digest_sz;
> + sctx->rsizw = sctx->rsiz / 8;
> +}
> +
> +static int sha3_224_init(struct shash_desc *desc)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> +
> + sha3_init(sctx, SHA3_224_DIGEST_SIZE);
> + return 0;
> +}
> +
> +static int sha3_256_init(struct shash_desc *desc)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> +
> + sha3_init(sctx, SHA3_256_DIGEST_SIZE);
> + return 0;
> +}
> +
> +static int sha3_384_init(struct shash_desc *desc)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> +
> + sha3_init(sctx, SHA3_384_DIGEST_SIZE);
> + return 0;
> +}
> +
> +static int sha3_512_init(struct shash_desc *desc)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> +
> + sha3_init(sctx, SHA3_512_DIGEST_SIZE);
> + return 0;
> +}
> +
> +static int sha3_update(struct shash_desc *desc, const u8 *data,
> + unsigned int len)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> + unsigned int done;
> + const u8 *src;
> +
> + done = 0;
> + src = data;
> +
> + if ((sctx->partial + len) > (sctx->rsiz - 1)) {
> + if (sctx->partial) {
> + done = -sctx->partial;
> + memcpy(sctx->buf + sctx->partial, data,
> + done + sctx->rsiz);
> + src = sctx->buf;
> + }
> +
> + do {
> + unsigned int i;
> +
> + for (i = 0; i < sctx->rsizw; i++)
> + sctx->st[i] ^= ((u64 *) src)[i];
> + keccakf(sctx->st);
> +
> + done += sctx->rsiz;
> + src = data + done;
> + } while (done + (sctx->rsiz - 1) < len);
> +
> + sctx->partial = 0;
> + }
> + memcpy(sctx->buf + sctx->partial, src, len - done);
> + sctx->partial += (len - done);
> +
> + return 0;
> +}
> +
> +static int sha3_final(struct shash_desc *desc, u8 *out)
> +{
> + struct sha3_state *sctx = shash_desc_ctx(desc);
> + unsigned int i, inlen = sctx->partial;
> +
> + sctx->buf[inlen++] = 0x06;
> + memset(sctx->buf + inlen, 0, sctx->rsiz - inlen);
> + sctx->buf[sctx->rsiz - 1] |= 0x80;
> +
> + for (i = 0; i < sctx->rsizw; i++)
> + sctx->st[i] ^= ((u64 *) sctx->buf)[i];
> +
> + keccakf(sctx->st);
> +
> + for (i = 0; i < sctx->rsizw; i++)
> + sctx->st[i] = cpu_to_le64(sctx->st[i]);
> +
> + memcpy(out, sctx->st, sctx->md_len);
> +
> + memset(sctx, 0, sizeof(*sctx));
> + return 0;
> +}
> +
> +static struct shash_alg sha3_224 = {
> + .digestsize = SHA3_224_DIGEST_SIZE,
> + .init = sha3_224_init,
> + .update = sha3_update,
> + .final = sha3_final,
> + .descsize = sizeof(struct sha3_state),
> + .base = {
> + .cra_name = "sha3-224",
> + .cra_driver_name = "sha3-224-generic",
> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
> + .cra_blocksize = SHA3_224_BLOCK_SIZE,
> + .cra_module = THIS_MODULE,
> + }
> +};
> +
> +static struct shash_alg sha3_256 = {
> + .digestsize = SHA3_256_DIGEST_SIZE,
> + .init = sha3_256_init,
> + .update = sha3_update,
> + .final = sha3_final,
> + .descsize = sizeof(struct sha3_state),
> + .base = {
> + .cra_name = "sha3-256",
> + .cra_driver_name = "sha3-256-generic",
> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
> + .cra_blocksize = SHA3_256_BLOCK_SIZE,
> + .cra_module = THIS_MODULE,
> + }
> +};
> +
> +static struct shash_alg sha3_384 = {
> + .digestsize = SHA3_384_DIGEST_SIZE,
> + .init = sha3_384_init,
> + .update = sha3_update,
> + .final = sha3_final,
> + .descsize = sizeof(struct sha3_state),
> + .base = {
> + .cra_name = "sha3-384",
> + .cra_driver_name = "sha3-384-generic",
> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
> + .cra_blocksize = SHA3_384_BLOCK_SIZE,
> + .cra_module = THIS_MODULE,
> + }
> +};
> +
> +static struct shash_alg sha3_512 = {
> + .digestsize = SHA3_512_DIGEST_SIZE,
> + .init = sha3_512_init,
> + .update = sha3_update,
> + .final = sha3_final,
> + .descsize = sizeof(struct sha3_state),
> + .base = {
> + .cra_name = "sha3-512",
> + .cra_driver_name = "sha3-512-generic",
> + .cra_flags = CRYPTO_ALG_TYPE_SHASH,
> + .cra_blocksize = SHA3_512_BLOCK_SIZE,
> + .cra_module = THIS_MODULE,
> + }
> +};
Shouldn't there be a priority here?
> +
> +static int __init sha3_generic_mod_init(void)
> +{
> + int ret;
> +
> + ret = crypto_register_shash(&sha3_224);
> + if (ret < 0)
> + goto err_out;
> + ret = crypto_register_shash(&sha3_256);
> + if (ret < 0)
> + goto err_out_224;
> + ret = crypto_register_shash(&sha3_384);
> + if (ret < 0)
> + goto err_out_256;
> + ret = crypto_register_shash(&sha3_512);
> + if (ret < 0)
> + goto err_out_384;
> +
> + return 0;
> +
> +err_out_384:
> + crypto_unregister_shash(&sha3_384);
> +err_out_256:
> + crypto_unregister_shash(&sha3_256);
> +err_out_224:
> + crypto_unregister_shash(&sha3_224);
> +err_out:
> + return ret;
> +}
> +
> +static void __exit sha3_generic_mod_fini(void)
> +{
> + crypto_unregister_shash(&sha3_224);
> + crypto_unregister_shash(&sha3_256);
> + crypto_unregister_shash(&sha3_384);
> + crypto_unregister_shash(&sha3_512);
> +}
> +
> +module_init(sha3_generic_mod_init);
> +module_exit(sha3_generic_mod_fini);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("SHA-3 Secure Hash Algorithm");
> +
> +MODULE_ALIAS("sha3-224");
> +MODULE_ALIAS("sha3-256");
> +MODULE_ALIAS("sha3-384");
> +MODULE_ALIAS("sha3-512");
MODULE_ALIAS_CRYPTO?
What about the aliases for cra_driver_name?
> diff --git a/include/crypto/sha3.h b/include/crypto/sha3.h
> new file mode 100644
> index 0000000..f4c9f68
> --- /dev/null
> +++ b/include/crypto/sha3.h
> @@ -0,0 +1,29 @@
> +/*
> + * Common values for SHA-3 algorithms
> + */
> +#ifndef __CRYPTO_SHA3_H__
> +#define __CRYPTO_SHA3_H__
> +
> +#define SHA3_224_DIGEST_SIZE (224 / 8)
> +#define SHA3_224_BLOCK_SIZE (200 - 2 * SHA3_224_DIGEST_SIZE)
> +
> +#define SHA3_256_DIGEST_SIZE (256 / 8)
> +#define SHA3_256_BLOCK_SIZE (200 - 2 * SHA3_256_DIGEST_SIZE)
> +
> +#define SHA3_384_DIGEST_SIZE (384 / 8)
> +#define SHA3_384_BLOCK_SIZE (200 - 2 * SHA3_384_DIGEST_SIZE)
> +
> +#define SHA3_512_DIGEST_SIZE (512 / 8)
> +#define SHA3_512_BLOCK_SIZE (200 - 2 * SHA3_512_DIGEST_SIZE)
> +
> +struct sha3_state {
> + u64 st[25];
> + unsigned int md_len;
> + unsigned int rsiz;
> + unsigned int rsizw;
> +
> + unsigned int partial;
> + u8 buf[SHA3_224_BLOCK_SIZE];
> +};
> +
> +#endif
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH] crypto: fix semicolon.cocci warnings
From: Stephan Mueller @ 2016-06-15 11:40 UTC (permalink / raw)
To: kbuild test robot; +Cc: kbuild-all, linux-crypto, Herbert Xu
In-Reply-To: <20160615111325.GA68889@ivytown2>
Am Mittwoch, 15. Juni 2016, 19:13:25 schrieb kbuild test robot:
Hi Fengguang,
> crypto/drbg.c:1637:39-40: Unneeded semicolon
>
>
> Remove unneeded semicolon.
Thank you!
>
> Generated by: scripts/coccinelle/misc/semicolon.cocci
>
> CC: Stephan Mueller <smueller@chronox.de>
> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Stephan Mueller <smueller@chronox.de>
> ---
>
> drbg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/crypto/drbg.c
> +++ b/crypto/drbg.c
> @@ -1634,7 +1634,7 @@ static int drbg_fini_sym_kernel(struct d
> drbg->ctr_handle = NULL;
>
> if (drbg->ctr_req)
> - skcipher_request_free(drbg->ctr_req);;
> + skcipher_request_free(drbg->ctr_req);
> drbg->ctr_req = NULL;
>
> kfree(drbg->ctr_null_value_buf);
Ciao
Stephan
^ permalink raw reply
* [PATCH] crypto: fix semicolon.cocci warnings
From: kbuild test robot @ 2016-06-15 11:13 UTC (permalink / raw)
Cc: kbuild-all, linux-crypto, Herbert Xu, Stephan Mueller
In-Reply-To: <201606151923.o07hQ3Ki%fengguang.wu@intel.com>
crypto/drbg.c:1637:39-40: Unneeded semicolon
Remove unneeded semicolon.
Generated by: scripts/coccinelle/misc/semicolon.cocci
CC: Stephan Mueller <smueller@chronox.de>
Signed-off-by: Fengguang Wu <fengguang.wu@intel.com>
---
drbg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1634,7 +1634,7 @@ static int drbg_fini_sym_kernel(struct d
drbg->ctr_handle = NULL;
if (drbg->ctr_req)
- skcipher_request_free(drbg->ctr_req);;
+ skcipher_request_free(drbg->ctr_req);
drbg->ctr_req = NULL;
kfree(drbg->ctr_null_value_buf);
^ permalink raw reply
* [cryptodev:master 47/51] crypto/drbg.c:1637:39-40: Unneeded semicolon
From: kbuild test robot @ 2016-06-15 11:13 UTC (permalink / raw)
Cc: kbuild-all, linux-crypto, Herbert Xu, Stephan Mueller
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 5a7de97309f5af4458b1a25a2a529a1a893c5269
commit: 355912852115cd8aa4ad02c25182ae615ce925fb [47/51] crypto: drbg - use CTR AES instead of ECB AES
coccinelle warnings: (new ones prefixed by >>)
>> crypto/drbg.c:1637:39-40: Unneeded semicolon
Please review and possibly fold the followup patch.
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
^ permalink raw reply
* RE: [PATCH 0/2] Add SHA-3 algorithm and test vectors.
From: Raveendra Padasalagi @ 2016-06-15 10:57 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jeff Garzik, Jeff Garzik
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list
In-Reply-To: <1465983719-8313-1-git-send-email-raveendra.padasalagi@broadcom.com>
The patch set can be fetched from iproc-sha3-v1 branch of
https://github.com/Broadcom/arm64-linux.git
Regards,
Raveendra
> -----Original Message-----
> From: Raveendra Padasalagi [mailto:raveendra.padasalagi@broadcom.com]
> Sent: 15 June 2016 15:20
> To: 'Herbert Xu'; 'David S. Miller'; 'linux-crypto@vger.kernel.org';
'linux-
> kernel@vger.kernel.org'; 'Jeff Garzik'; 'Jeff Garzik'
> Cc: 'Jon Mason'; 'Florian Fainelli'; Anup Patel; 'Ray Jui'; 'Scott
Branden'; Pramod
> Kumar; 'bcm-kernel-feedback-list@broadcom.com'
> Subject: RE: [PATCH 0/2] Add SHA-3 algorithm and test vectors.
>
> Forgot to add Jeff Garzik in the email list.
>
> ++ Jeff Garzik.
>
>
> Regards,
> Raveendra
>
> > -----Original Message-----
> > From: Raveendra Padasalagi [mailto:raveendra.padasalagi@broadcom.com]
> > Sent: 15 June 2016 15:12
> > To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux-
> > kernel@vger.kernel.org
> > Cc: Jon Mason; Florian Fainelli; Anup Patel; Ray Jui; Scott Branden;
> > Pramod Kumar; bcm-kernel-feedback-list@broadcom.com; Raveendra
> > Padasalagi
> > Subject: [PATCH 0/2] Add SHA-3 algorithm and test vectors.
> >
> > This patchset adds the implementation of SHA-3 algorithm in software
> > and it's based on original implementation pushed in patch
> > https://lwn.net/Articles/518415/ with additional changes to match the
> > padding rules specified in SHA-3 specification.
> >
> > This patchset also includes changes in tcrypt module to add support
> > for SHA-3 algorithms test and related test vectors for basic testing.
> >
> > Broadcom Secure Processing Unit-2(SPU-2) engine supports offloading of
> > SHA-3 operations in hardware, in order to add SHA-3 support in SPU-2
> > driver we needed to have the software implementation and test
framework in
> place.
> >
> > The patchset is based on v4.7-rc1 tag and its tested on Broadcom
> > NorthStar2 SoC.
> >
> > Jeff Garzik (1):
> > Crypto: Add SHA-3 hash algorithm
> >
> > Raveendra Padasalagi (1):
> > Crypto: Add SHA-3 Test's in tcrypt
> >
> > crypto/Kconfig | 10 ++
> > crypto/Makefile | 1 +
> > crypto/sha3_generic.c | 296
> > ++++++++++++++++++++++++++++++++++++++++++++++++++
> > crypto/tcrypt.c | 53 ++++++++-
> > crypto/testmgr.c | 40 +++++++
> > crypto/testmgr.h | 125 +++++++++++++++++++++
> > include/crypto/sha3.h | 29 +++++
> > 7 files changed, 553 insertions(+), 1 deletion(-) create mode 100644
> > crypto/sha3_generic.c create mode 100644 include/crypto/sha3.h
> >
> > --
> > 1.9.1
^ permalink raw reply
* select on non-existing Kconfig option CRC32C
From: Andreas Ziegler @ 2016-06-15 10:00 UTC (permalink / raw)
To: Hendrik Brueckner
Cc: Martin Schwidefsky, Herbert Xu, David S. Miller, linux-crypto,
linux-kernel
Hi Hendrik,
your patch "s390/crc32-vx: add crypto API module for optimized CRC-32
algorithms" showed up in linux-next today (next-20160615) as commit 364148e0b195.
The patch defines the Kconfig option CRYPTO_CRC32_S390 which 'select's CRC32C.
However, this should probably have been CRYPTO_CRC32C, as CRC32C does not exist.
Should I prepare a trivial patch to fix this up or would you like to do that on
your side?
I found this issue by comparing yesterday's tree and today's tree using
'scripts/checkkconfigsymbols -f -d next-20160614..next-20160615'.
Best regards,
Andreas
^ permalink raw reply
* [RESEND PATCH 2/2] ARM64: dts: meson-gxbb: Add Hardware Random Generator node
From: Neil Armstrong @ 2016-06-15 10:01 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu
Cc: Neil Armstrong, linux-arm-kernel, linux-amlogic, linux-kernel,
linux-crypto, devicetree
In-Reply-To: <1465984906-17840-1-git-send-email-narmstrong@baylibre.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
---
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
index 063e3b6..806b903 100644
--- a/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
+++ b/arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi
@@ -221,6 +221,11 @@
#size-cells = <2>;
ranges = <0x0 0x0 0x0 0xc8834000 0x0 0x2000>;
+ rng {
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0x0 0x0 0x4>;
+ };
+
pinctrl_periphs: pinctrl@4b0 {
compatible = "amlogic,meson-gxbb-periphs-pinctrl";
#address-cells = <2>;
--
2.7.0
^ permalink raw reply related
* [RESEND PATCH 1/2] dt-bindings: hwrng: Add Amlogic Meson Hardware Random Generator bindings
From: Neil Armstrong @ 2016-06-15 10:01 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu
Cc: Neil Armstrong, linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
devicetree-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1465984906-17840-1-git-send-email-narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
Acked-by: Rob Herring <robh-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Signed-off-by: Neil Armstrong <narmstrong-rdvid1DuHRBWk0Htik3J/w@public.gmane.org>
---
.../devicetree/bindings/rng/amlogic,meson-rng.txt | 14 ++++++++++++++
1 file changed, 14 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
diff --git a/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
new file mode 100644
index 0000000..202f2d0
--- /dev/null
+++ b/Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
@@ -0,0 +1,14 @@
+Amlogic Meson Random number generator
+=====================================
+
+Required properties:
+
+- compatible : should be "amlogic,meson-rng"
+- reg : Specifies base physical address and size of the registers.
+
+Example:
+
+rng {
+ compatible = "amlogic,meson-rng";
+ reg = <0x0 0xc8834000 0x0 0x4>;
+};
--
2.7.0
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* [RESEND PATCH 0/2] hw_random: Add Amlogic Meson SoCs Random Generator driver
From: Neil Armstrong @ 2016-06-15 10:01 UTC (permalink / raw)
To: Matt Mackall, Herbert Xu
Cc: Neil Armstrong, linux-arm-kernel, linux-amlogic, linux-kernel,
linux-crypto
NOTE: This is a resent of the DT Bindings and DTSI patches based on the Amlogic DT 64bit
GIT pull request from Kevin Hilman at [1].
Changes since v2 at http://lkml.kernel.org/r/1465546915-24229-1-git-send-email-narmstrong@baylibre.com :
- Move rng peripheral node into periphs simple-bus node
Add support for the Amlogic Meson SoCs Hardware Random generator as a hw_random char driver.
The generator is a single 32bit wide register.
Also adds the Meson GXBB SoC DTSI node and corresponding DT bindings.
Changes since v1 at http://lkml.kernel.org/r/1464943621-18278-1-git-send-email-narmstrong@baylibre.com :
- change to depend on ARCH_MESON || COMPILE_TEST
- check buffer max size in read
[1] [GIT PULL] Amlogic DT 64-bit changes for v4.8 : http://lkml.kernel.org/r/7hshwfbiit.fsf@baylibre.com
Neil Armstrong (2):
dt-bindings: hwrng: Add Amlogic Meson Hardware Random Generator
bindings
ARM64: dts: meson-gxbb: Add Hardware Random Generator node
.../devicetree/bindings/rng/amlogic,meson-rng.txt | 14 ++++++++++++++
arch/arm64/boot/dts/amlogic/meson-gxbb.dtsi | 5 +++++
2 files changed, 19 insertions(+)
create mode 100644 Documentation/devicetree/bindings/rng/amlogic,meson-rng.txt
--
2.7.0
^ permalink raw reply
* RE: [PATCH 2/2] Crypto: Add SHA-3 Test's in tcrypt
From: Raveendra Padasalagi @ 2016-06-15 9:50 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jeff Garzik, Jeff Garzik
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list
In-Reply-To: <1465983719-8313-3-git-send-email-raveendra.padasalagi@broadcom.com>
Forgot to add Jeff Garzik in the email list.
++ Jeff Garzik.
Regards,
Raveendra
> -----Original Message-----
> From: Raveendra Padasalagi [mailto:raveendra.padasalagi@broadcom.com]
> Sent: 15 June 2016 15:12
> To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Jon Mason; Florian Fainelli; Anup Patel; Ray Jui; Scott Branden;
Pramod
> Kumar; bcm-kernel-feedback-list@broadcom.com; Raveendra Padasalagi
> Subject: [PATCH 2/2] Crypto: Add SHA-3 Test's in tcrypt
>
> Added support for SHA-3 algorithm test's in tcrypt module and related
test
> vectors.
>
> Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
> ---
> crypto/tcrypt.c | 53 ++++++++++++++++++++++- crypto/testmgr.c | 40
> ++++++++++++++++++ crypto/testmgr.h | 125
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 217 insertions(+), 1 deletion(-)
>
> diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c index 579dce0..4675459
100644
> --- a/crypto/tcrypt.c
> +++ b/crypto/tcrypt.c
> @@ -72,7 +72,8 @@ static char *check[] = {
> "cast6", "arc4", "michael_mic", "deflate", "crc32c", "tea",
"xtea",
> "khazad", "wp512", "wp384", "wp256", "tnepres", "xeta", "fcrypt",
> "camellia", "seed", "salsa20", "rmd128", "rmd160", "rmd256",
> "rmd320",
> - "lzo", "cts", "zlib", NULL
> + "lzo", "cts", "zlib", "sha3-224", "sha3-256", "sha3-384",
"sha3-512",
> + NULL
> };
>
> struct tcrypt_result {
> @@ -1284,6 +1285,22 @@ static int do_test(const char *alg, u32 type, u32
> mask, int m)
> ret += tcrypt_test("crct10dif");
> break;
>
> + case 48:
> + ret += tcrypt_test("sha3-224");
> + break;
> +
> + case 49:
> + ret += tcrypt_test("sha3-256");
> + break;
> +
> + case 50:
> + ret += tcrypt_test("sha3-384");
> + break;
> +
> + case 51:
> + ret += tcrypt_test("sha3-512");
> + break;
> +
> case 100:
> ret += tcrypt_test("hmac(md5)");
> break;
> @@ -1691,6 +1708,22 @@ static int do_test(const char *alg, u32 type, u32
> mask, int m)
> test_hash_speed("poly1305", sec, poly1305_speed_template);
> if (mode > 300 && mode < 400) break;
>
> + case 322:
> + test_hash_speed("sha3-224", sec,
> generic_hash_speed_template);
> + if (mode > 300 && mode < 400) break;
> +
> + case 323:
> + test_hash_speed("sha3-256", sec,
> generic_hash_speed_template);
> + if (mode > 300 && mode < 400) break;
> +
> + case 324:
> + test_hash_speed("sha3-384", sec,
> generic_hash_speed_template);
> + if (mode > 300 && mode < 400) break;
> +
> + case 325:
> + test_hash_speed("sha3-512", sec,
> generic_hash_speed_template);
> + if (mode > 300 && mode < 400) break;
> +
> case 399:
> break;
>
> @@ -1770,6 +1803,24 @@ static int do_test(const char *alg, u32 type, u32
> mask, int m)
> test_ahash_speed("rmd320", sec,
> generic_hash_speed_template);
> if (mode > 400 && mode < 500) break;
>
> + case 418:
> + test_ahash_speed("sha3-224", sec,
> generic_hash_speed_template);
> + if (mode > 400 && mode < 500) break;
> +
> + case 419:
> + test_ahash_speed("sha3-256", sec,
> generic_hash_speed_template);
> + if (mode > 400 && mode < 500) break;
> +
> + case 420:
> + test_ahash_speed("sha3-384", sec,
> generic_hash_speed_template);
> + if (mode > 400 && mode < 500) break;
> +
> +
> + case 421:
> + test_ahash_speed("sha3-512", sec,
> generic_hash_speed_template);
> + if (mode > 400 && mode < 500) break;
> +
> +
> case 499:
> break;
>
> diff --git a/crypto/testmgr.c b/crypto/testmgr.c index c727fb0..b773a56
100644
> --- a/crypto/testmgr.c
> +++ b/crypto/testmgr.c
> @@ -3659,6 +3659,46 @@ static const struct alg_test_desc
alg_test_descs[] = {
> }
> }
> }, {
> + .alg = "sha3-224",
> + .test = alg_test_hash,
> + .fips_allowed = 1,
> + .suite = {
> + .hash = {
> + .vecs = sha3_224_tv_template,
> + .count = SHA3_224_TEST_VECTORS
> + }
> + }
> + }, {
> + .alg = "sha3-256",
> + .test = alg_test_hash,
> + .fips_allowed = 1,
> + .suite = {
> + .hash = {
> + .vecs = sha3_256_tv_template,
> + .count = SHA3_256_TEST_VECTORS
> + }
> + }
> + }, {
> + .alg = "sha3-384",
> + .test = alg_test_hash,
> + .fips_allowed = 1,
> + .suite = {
> + .hash = {
> + .vecs = sha3_384_tv_template,
> + .count = SHA3_384_TEST_VECTORS
> + }
> + }
> + }, {
> + .alg = "sha3-512",
> + .test = alg_test_hash,
> + .fips_allowed = 1,
> + .suite = {
> + .hash = {
> + .vecs = sha3_512_tv_template,
> + .count = SHA3_512_TEST_VECTORS
> + }
> + }
> + }, {
> .alg = "sha384",
> .test = alg_test_hash,
> .fips_allowed = 1,
> diff --git a/crypto/testmgr.h b/crypto/testmgr.h index 487ec88..b70e3c9
> 100644
> --- a/crypto/testmgr.h
> +++ b/crypto/testmgr.h
> @@ -376,6 +376,131 @@ static struct hash_testvec md4_tv_template [] = {
> },
> };
>
> +#define SHA3_224_TEST_VECTORS 3
> +static struct hash_testvec sha3_224_tv_template[] = {
> + {
> + .plaintext = "",
> + .digest = "\x6b\x4e\x03\x42\x36\x67\xdb\xb7"
> + "\x3b\x6e\x15\x45\x4f\x0e\xb1\xab"
> + "\xd4\x59\x7f\x9a\x1b\x07\x8e\x3f"
> + "\x5b\x5a\x6b\xc7",
> + }, {
> + .plaintext = "a",
> + .psize = 1,
> + .digest = "\x9e\x86\xff\x69\x55\x7c\xa9\x5f"
> + "\x40\x5f\x08\x12\x69\x68\x5b\x38"
> + "\xe3\xa8\x19\xb3\x09\xee\x94\x2f"
> + "\x48\x2b\x6a\x8b",
> + }, {
> + .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
> + "jklmklmnlmnomnopnopq",
> + .psize = 56,
> + .digest = "\x8a\x24\x10\x8b\x15\x4a\xda\x21"
> + "\xc9\xfd\x55\x74\x49\x44\x79\xba"
> + "\x5c\x7e\x7a\xb7\x6e\xf2\x64\xea"
> + "\xd0\xfc\xce\x33",
> + },
> +};
> +
> +#define SHA3_256_TEST_VECTORS 3
> +static struct hash_testvec sha3_256_tv_template[] = {
> + {
> + .plaintext = "",
> + .digest = "\xa7\xff\xc6\xf8\xbf\x1e\xd7\x66"
> + "\x51\xc1\x47\x56\xa0\x61\xd6\x62"
> + "\xf5\x80\xff\x4d\xe4\x3b\x49\xfa"
> + "\x82\xd8\x0a\x4b\x80\xf8\x43\x4a",
> + }, {
> + .plaintext = "a",
> + .psize = 1,
> + .digest = "\x80\x08\x4b\xf2\xfb\xa0\x24\x75"
> + "\x72\x6f\xeb\x2c\xab\x2d\x82\x15"
> + "\xea\xb1\x4b\xc6\xbd\xd8\xbf\xb2"
> + "\xc8\x15\x12\x57\x03\x2e\xcd\x8b",
> + }, {
> + .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
> + "jklmklmnlmnomnopnopq",
> + .psize = 56,
> + .digest = "\x41\xc0\xdb\xa2\xa9\xd6\x24\x08"
> + "\x49\x10\x03\x76\xa8\x23\x5e\x2c"
> + "\x82\xe1\xb9\x99\x8a\x99\x9e\x21"
> + "\xdb\x32\xdd\x97\x49\x6d\x33\x76",
> + },
> +};
> +
> +
> +#define SHA3_384_TEST_VECTORS 3
> +static struct hash_testvec sha3_384_tv_template[] = {
> + {
> + .plaintext = "",
> + .digest = "\x0c\x63\xa7\x5b\x84\x5e\x4f\x7d"
> + "\x01\x10\x7d\x85\x2e\x4c\x24\x85"
> + "\xc5\x1a\x50\xaa\xaa\x94\xfc\x61"
> + "\x99\x5e\x71\xbb\xee\x98\x3a\x2a"
> + "\xc3\x71\x38\x31\x26\x4a\xdb\x47"
> + "\xfb\x6b\xd1\xe0\x58\xd5\xf0\x04",
> + }, {
> + .plaintext = "a",
> + .psize = 1,
> + .digest = "\x18\x15\xf7\x74\xf3\x20\x49\x1b"
> + "\x48\x56\x9e\xfe\xc7\x94\xd2\x49"
> + "\xee\xb5\x9a\xae\x46\xd2\x2b\xf7"
> + "\x7d\xaf\xe2\x5c\x5e\xdc\x28\xd7"
> + "\xea\x44\xf9\x3e\xe1\x23\x4a\xa8"
> + "\x8f\x61\xc9\x19\x12\xa4\xcc\xd9",
> + }, {
> + .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
> + "jklmklmnlmnomnopnopq",
> + .psize = 56,
> + .digest = "\x99\x1c\x66\x57\x55\xeb\x3a\x4b"
> + "\x6b\xbd\xfb\x75\xc7\x8a\x49\x2e"
> + "\x8c\x56\xa2\x2c\x5c\x4d\x7e\x42"
> + "\x9b\xfd\xbc\x32\xb9\xd4\xad\x5a"
> + "\xa0\x4a\x1f\x07\x6e\x62\xfe\xa1"
> + "\x9e\xef\x51\xac\xd0\x65\x7c\x22",
> + },
> +};
> +
> +
> +#define SHA3_512_TEST_VECTORS 3
> +static struct hash_testvec sha3_512_tv_template[] = {
> + {
> + .plaintext = "",
> + .digest = "\xa6\x9f\x73\xcc\xa2\x3a\x9a\xc5"
> + "\xc8\xb5\x67\xdc\x18\x5a\x75\x6e"
> + "\x97\xc9\x82\x16\x4f\xe2\x58\x59"
> + "\xe0\xd1\xdc\xc1\x47\x5c\x80\xa6"
> + "\x15\xb2\x12\x3a\xf1\xf5\xf9\x4c"
> + "\x11\xe3\xe9\x40\x2c\x3a\xc5\x58"
> + "\xf5\x00\x19\x9d\x95\xb6\xd3\xe3"
> + "\x01\x75\x85\x86\x28\x1d\xcd\x26",
> + }, {
> + .plaintext = "a",
> + .psize = 1,
> + .digest = "\x69\x7f\x2d\x85\x61\x72\xcb\x83"
> + "\x09\xd6\xb8\xb9\x7d\xac\x4d\xe3"
> + "\x44\xb5\x49\xd4\xde\xe6\x1e\xdf"
> + "\xb4\x96\x2d\x86\x98\xb7\xfa\x80"
> + "\x3f\x4f\x93\xff\x24\x39\x35\x86"
> + "\xe2\x8b\x5b\x95\x7a\xc3\xd1\xd3"
> + "\x69\x42\x0c\xe5\x33\x32\x71\x2f"
> + "\x99\x7b\xd3\x36\xd0\x9a\xb0\x2a",
> + }, {
> + .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
> + "jklmklmnlmnomnopnopq",
> + .psize = 56,
> + .digest = "\x04\xa3\x71\xe8\x4e\xcf\xb5\xb8"
> + "\xb7\x7c\xb4\x86\x10\xfc\xa8\x18"
> + "\x2d\xd4\x57\xce\x6f\x32\x6a\x0f"
> + "\xd3\xd7\xec\x2f\x1e\x91\x63\x6d"
> + "\xee\x69\x1f\xbe\x0c\x98\x53\x02"
> + "\xba\x1b\x0d\x8d\xc7\x8c\x08\x63"
> + "\x46\xb5\x33\xb4\x9c\x03\x0d\x99"
> + "\xa2\x7d\xaf\x11\x39\xd6\xe7\x5e",
> + },
> +};
> +
> +
> /*
> * MD5 test vectors from RFC1321
> */
> --
> 1.9.1
^ permalink raw reply
* RE: [PATCH 0/2] Add SHA-3 algorithm and test vectors.
From: Raveendra Padasalagi @ 2016-06-15 9:50 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel,
Jeff Garzik, Jeff Garzik
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list
In-Reply-To: <1465983719-8313-1-git-send-email-raveendra.padasalagi@broadcom.com>
Forgot to add Jeff Garzik in the email list.
++ Jeff Garzik.
Regards,
Raveendra
> -----Original Message-----
> From: Raveendra Padasalagi [mailto:raveendra.padasalagi@broadcom.com]
> Sent: 15 June 2016 15:12
> To: Herbert Xu; David S. Miller; linux-crypto@vger.kernel.org; linux-
> kernel@vger.kernel.org
> Cc: Jon Mason; Florian Fainelli; Anup Patel; Ray Jui; Scott Branden;
Pramod
> Kumar; bcm-kernel-feedback-list@broadcom.com; Raveendra Padasalagi
> Subject: [PATCH 0/2] Add SHA-3 algorithm and test vectors.
>
> This patchset adds the implementation of SHA-3 algorithm in software and
it's
> based on original implementation pushed in patch
> https://lwn.net/Articles/518415/ with additional changes to match the
padding
> rules specified in SHA-3 specification.
>
> This patchset also includes changes in tcrypt module to add support for
SHA-3
> algorithms test and related test vectors for basic testing.
>
> Broadcom Secure Processing Unit-2(SPU-2) engine supports offloading of
SHA-3
> operations in hardware, in order to add SHA-3 support in SPU-2 driver we
> needed to have the software implementation and test framework in place.
>
> The patchset is based on v4.7-rc1 tag and its tested on Broadcom
NorthStar2
> SoC.
>
> Jeff Garzik (1):
> Crypto: Add SHA-3 hash algorithm
>
> Raveendra Padasalagi (1):
> Crypto: Add SHA-3 Test's in tcrypt
>
> crypto/Kconfig | 10 ++
> crypto/Makefile | 1 +
> crypto/sha3_generic.c | 296
> ++++++++++++++++++++++++++++++++++++++++++++++++++
> crypto/tcrypt.c | 53 ++++++++-
> crypto/testmgr.c | 40 +++++++
> crypto/testmgr.h | 125 +++++++++++++++++++++
> include/crypto/sha3.h | 29 +++++
> 7 files changed, 553 insertions(+), 1 deletion(-) create mode 100644
> crypto/sha3_generic.c create mode 100644 include/crypto/sha3.h
>
> --
> 1.9.1
^ permalink raw reply
* [PATCH 2/2] Crypto: Add SHA-3 Test's in tcrypt
From: Raveendra Padasalagi @ 2016-06-15 9:41 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Raveendra Padasalagi
In-Reply-To: <1465983719-8313-1-git-send-email-raveendra.padasalagi@broadcom.com>
Added support for SHA-3 algorithm test's
in tcrypt module and related test vectors.
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
---
crypto/tcrypt.c | 53 ++++++++++++++++++++++-
crypto/testmgr.c | 40 ++++++++++++++++++
crypto/testmgr.h | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 217 insertions(+), 1 deletion(-)
diff --git a/crypto/tcrypt.c b/crypto/tcrypt.c
index 579dce0..4675459 100644
--- a/crypto/tcrypt.c
+++ b/crypto/tcrypt.c
@@ -72,7 +72,8 @@ static char *check[] = {
"cast6", "arc4", "michael_mic", "deflate", "crc32c", "tea", "xtea",
"khazad", "wp512", "wp384", "wp256", "tnepres", "xeta", "fcrypt",
"camellia", "seed", "salsa20", "rmd128", "rmd160", "rmd256", "rmd320",
- "lzo", "cts", "zlib", NULL
+ "lzo", "cts", "zlib", "sha3-224", "sha3-256", "sha3-384", "sha3-512",
+ NULL
};
struct tcrypt_result {
@@ -1284,6 +1285,22 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
ret += tcrypt_test("crct10dif");
break;
+ case 48:
+ ret += tcrypt_test("sha3-224");
+ break;
+
+ case 49:
+ ret += tcrypt_test("sha3-256");
+ break;
+
+ case 50:
+ ret += tcrypt_test("sha3-384");
+ break;
+
+ case 51:
+ ret += tcrypt_test("sha3-512");
+ break;
+
case 100:
ret += tcrypt_test("hmac(md5)");
break;
@@ -1691,6 +1708,22 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
test_hash_speed("poly1305", sec, poly1305_speed_template);
if (mode > 300 && mode < 400) break;
+ case 322:
+ test_hash_speed("sha3-224", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 323:
+ test_hash_speed("sha3-256", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 324:
+ test_hash_speed("sha3-384", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
+ case 325:
+ test_hash_speed("sha3-512", sec, generic_hash_speed_template);
+ if (mode > 300 && mode < 400) break;
+
case 399:
break;
@@ -1770,6 +1803,24 @@ static int do_test(const char *alg, u32 type, u32 mask, int m)
test_ahash_speed("rmd320", sec, generic_hash_speed_template);
if (mode > 400 && mode < 500) break;
+ case 418:
+ test_ahash_speed("sha3-224", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+ case 419:
+ test_ahash_speed("sha3-256", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+ case 420:
+ test_ahash_speed("sha3-384", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+
+ case 421:
+ test_ahash_speed("sha3-512", sec, generic_hash_speed_template);
+ if (mode > 400 && mode < 500) break;
+
+
case 499:
break;
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c727fb0..b773a56 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -3659,6 +3659,46 @@ static const struct alg_test_desc alg_test_descs[] = {
}
}
}, {
+ .alg = "sha3-224",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_224_tv_template,
+ .count = SHA3_224_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-256",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_256_tv_template,
+ .count = SHA3_256_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-384",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_384_tv_template,
+ .count = SHA3_384_TEST_VECTORS
+ }
+ }
+ }, {
+ .alg = "sha3-512",
+ .test = alg_test_hash,
+ .fips_allowed = 1,
+ .suite = {
+ .hash = {
+ .vecs = sha3_512_tv_template,
+ .count = SHA3_512_TEST_VECTORS
+ }
+ }
+ }, {
.alg = "sha384",
.test = alg_test_hash,
.fips_allowed = 1,
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index 487ec88..b70e3c9 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -376,6 +376,131 @@ static struct hash_testvec md4_tv_template [] = {
},
};
+#define SHA3_224_TEST_VECTORS 3
+static struct hash_testvec sha3_224_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\x6b\x4e\x03\x42\x36\x67\xdb\xb7"
+ "\x3b\x6e\x15\x45\x4f\x0e\xb1\xab"
+ "\xd4\x59\x7f\x9a\x1b\x07\x8e\x3f"
+ "\x5b\x5a\x6b\xc7",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x9e\x86\xff\x69\x55\x7c\xa9\x5f"
+ "\x40\x5f\x08\x12\x69\x68\x5b\x38"
+ "\xe3\xa8\x19\xb3\x09\xee\x94\x2f"
+ "\x48\x2b\x6a\x8b",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x8a\x24\x10\x8b\x15\x4a\xda\x21"
+ "\xc9\xfd\x55\x74\x49\x44\x79\xba"
+ "\x5c\x7e\x7a\xb7\x6e\xf2\x64\xea"
+ "\xd0\xfc\xce\x33",
+ },
+};
+
+#define SHA3_256_TEST_VECTORS 3
+static struct hash_testvec sha3_256_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\xa7\xff\xc6\xf8\xbf\x1e\xd7\x66"
+ "\x51\xc1\x47\x56\xa0\x61\xd6\x62"
+ "\xf5\x80\xff\x4d\xe4\x3b\x49\xfa"
+ "\x82\xd8\x0a\x4b\x80\xf8\x43\x4a",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x80\x08\x4b\xf2\xfb\xa0\x24\x75"
+ "\x72\x6f\xeb\x2c\xab\x2d\x82\x15"
+ "\xea\xb1\x4b\xc6\xbd\xd8\xbf\xb2"
+ "\xc8\x15\x12\x57\x03\x2e\xcd\x8b",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x41\xc0\xdb\xa2\xa9\xd6\x24\x08"
+ "\x49\x10\x03\x76\xa8\x23\x5e\x2c"
+ "\x82\xe1\xb9\x99\x8a\x99\x9e\x21"
+ "\xdb\x32\xdd\x97\x49\x6d\x33\x76",
+ },
+};
+
+
+#define SHA3_384_TEST_VECTORS 3
+static struct hash_testvec sha3_384_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\x0c\x63\xa7\x5b\x84\x5e\x4f\x7d"
+ "\x01\x10\x7d\x85\x2e\x4c\x24\x85"
+ "\xc5\x1a\x50\xaa\xaa\x94\xfc\x61"
+ "\x99\x5e\x71\xbb\xee\x98\x3a\x2a"
+ "\xc3\x71\x38\x31\x26\x4a\xdb\x47"
+ "\xfb\x6b\xd1\xe0\x58\xd5\xf0\x04",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x18\x15\xf7\x74\xf3\x20\x49\x1b"
+ "\x48\x56\x9e\xfe\xc7\x94\xd2\x49"
+ "\xee\xb5\x9a\xae\x46\xd2\x2b\xf7"
+ "\x7d\xaf\xe2\x5c\x5e\xdc\x28\xd7"
+ "\xea\x44\xf9\x3e\xe1\x23\x4a\xa8"
+ "\x8f\x61\xc9\x19\x12\xa4\xcc\xd9",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x99\x1c\x66\x57\x55\xeb\x3a\x4b"
+ "\x6b\xbd\xfb\x75\xc7\x8a\x49\x2e"
+ "\x8c\x56\xa2\x2c\x5c\x4d\x7e\x42"
+ "\x9b\xfd\xbc\x32\xb9\xd4\xad\x5a"
+ "\xa0\x4a\x1f\x07\x6e\x62\xfe\xa1"
+ "\x9e\xef\x51\xac\xd0\x65\x7c\x22",
+ },
+};
+
+
+#define SHA3_512_TEST_VECTORS 3
+static struct hash_testvec sha3_512_tv_template[] = {
+ {
+ .plaintext = "",
+ .digest = "\xa6\x9f\x73\xcc\xa2\x3a\x9a\xc5"
+ "\xc8\xb5\x67\xdc\x18\x5a\x75\x6e"
+ "\x97\xc9\x82\x16\x4f\xe2\x58\x59"
+ "\xe0\xd1\xdc\xc1\x47\x5c\x80\xa6"
+ "\x15\xb2\x12\x3a\xf1\xf5\xf9\x4c"
+ "\x11\xe3\xe9\x40\x2c\x3a\xc5\x58"
+ "\xf5\x00\x19\x9d\x95\xb6\xd3\xe3"
+ "\x01\x75\x85\x86\x28\x1d\xcd\x26",
+ }, {
+ .plaintext = "a",
+ .psize = 1,
+ .digest = "\x69\x7f\x2d\x85\x61\x72\xcb\x83"
+ "\x09\xd6\xb8\xb9\x7d\xac\x4d\xe3"
+ "\x44\xb5\x49\xd4\xde\xe6\x1e\xdf"
+ "\xb4\x96\x2d\x86\x98\xb7\xfa\x80"
+ "\x3f\x4f\x93\xff\x24\x39\x35\x86"
+ "\xe2\x8b\x5b\x95\x7a\xc3\xd1\xd3"
+ "\x69\x42\x0c\xe5\x33\x32\x71\x2f"
+ "\x99\x7b\xd3\x36\xd0\x9a\xb0\x2a",
+ }, {
+ .plaintext = "abcdbcdecdefdefgefghfghighijhijkijkl"
+ "jklmklmnlmnomnopnopq",
+ .psize = 56,
+ .digest = "\x04\xa3\x71\xe8\x4e\xcf\xb5\xb8"
+ "\xb7\x7c\xb4\x86\x10\xfc\xa8\x18"
+ "\x2d\xd4\x57\xce\x6f\x32\x6a\x0f"
+ "\xd3\xd7\xec\x2f\x1e\x91\x63\x6d"
+ "\xee\x69\x1f\xbe\x0c\x98\x53\x02"
+ "\xba\x1b\x0d\x8d\xc7\x8c\x08\x63"
+ "\x46\xb5\x33\xb4\x9c\x03\x0d\x99"
+ "\xa2\x7d\xaf\x11\x39\xd6\xe7\x5e",
+ },
+};
+
+
/*
* MD5 test vectors from RFC1321
*/
--
1.9.1
^ permalink raw reply related
* [PATCH 1/2] Crypto: Add SHA-3 hash algorithm
From: Raveendra Padasalagi @ 2016-06-15 9:41 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Jeff Garzik, Jeff Garzik,
Raveendra Padasalagi
In-Reply-To: <1465983719-8313-1-git-send-email-raveendra.padasalagi@broadcom.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=y, Size: 10425 bytes --]
From: Jeff Garzik <jeff@garzik.org>
This patch adds the implementation of SHA3 algorithm
in software and it's based on original implementation
pushed in patch https://lwn.net/Articles/518415/ with
additional changes to match the padding rules specified
in SHA-3 specification.
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Signed-off-by: Raveendra Padasalagi <raveendra.padasalagi@broadcom.com>
---
crypto/Kconfig | 10 ++
crypto/Makefile | 1 +
crypto/sha3_generic.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++
include/crypto/sha3.h | 29 +++++
4 files changed, 336 insertions(+)
create mode 100644 crypto/sha3_generic.c
create mode 100644 include/crypto/sha3.h
diff --git a/crypto/Kconfig b/crypto/Kconfig
index 1d33beb..83ee8cb 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -750,6 +750,16 @@ config CRYPTO_SHA512_SPARC64
SHA-512 secure hash standard (DFIPS 180-2) implemented
using sparc64 crypto instructions, when available.
+config CRYPTO_SHA3
+ tristate "SHA3 digest algorithm"
+ select CRYPTO_HASH
+ help
+ SHA-3 secure hash standard (DFIPS 202). It's based on
+ cryptographic sponge function family called Keccak.
+
+ References:
+ http://keccak.noekeon.org/
+
config CRYPTO_TGR192
tristate "Tiger digest algorithms"
select CRYPTO_HASH
diff --git a/crypto/Makefile b/crypto/Makefile
index 4f4ef7e..0b82c47 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_CRYPTO_RMD320) += rmd320.o
obj-$(CONFIG_CRYPTO_SHA1) += sha1_generic.o
obj-$(CONFIG_CRYPTO_SHA256) += sha256_generic.o
obj-$(CONFIG_CRYPTO_SHA512) += sha512_generic.o
+obj-$(CONFIG_CRYPTO_SHA3) += sha3_generic.o
obj-$(CONFIG_CRYPTO_WP512) += wp512.o
obj-$(CONFIG_CRYPTO_TGR192) += tgr192.o
obj-$(CONFIG_CRYPTO_GF128MUL) += gf128mul.o
diff --git a/crypto/sha3_generic.c b/crypto/sha3_generic.c
new file mode 100644
index 0000000..162dfc3
--- /dev/null
+++ b/crypto/sha3_generic.c
@@ -0,0 +1,296 @@
+/*
+ * Cryptographic API.
+ *
+ * SHA-3, as specified in
+ * http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.202.pdf
+ *
+ * SHA-3 code by Jeff Garzik <jeff@garzik.org>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the Free
+ * Software Foundation; either version 2 of the License, or (at your option)•
+ * any later version.
+ *
+ */
+#include <crypto/internal/hash.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/types.h>
+#include <crypto/sha3.h>
+#include <asm/byteorder.h>
+
+#define KECCAK_ROUNDS 24
+
+#define ROTL64(x, y) (((x) << (y)) | ((x) >> (64 - (y))))
+
+static const u64 keccakf_rndc[24] = {
+ 0x0000000000000001, 0x0000000000008082, 0x800000000000808a,
+ 0x8000000080008000, 0x000000000000808b, 0x0000000080000001,
+ 0x8000000080008081, 0x8000000000008009, 0x000000000000008a,
+ 0x0000000000000088, 0x0000000080008009, 0x000000008000000a,
+ 0x000000008000808b, 0x800000000000008b, 0x8000000000008089,
+ 0x8000000000008003, 0x8000000000008002, 0x8000000000000080,
+ 0x000000000000800a, 0x800000008000000a, 0x8000000080008081,
+ 0x8000000000008080, 0x0000000080000001, 0x8000000080008008
+};
+
+static const int keccakf_rotc[24] = {
+ 1, 3, 6, 10, 15, 21, 28, 36, 45, 55, 2, 14,
+ 27, 41, 56, 8, 25, 43, 62, 18, 39, 61, 20, 44
+};
+
+static const int keccakf_piln[24] = {
+ 10, 7, 11, 17, 18, 3, 5, 16, 8, 21, 24, 4,
+ 15, 23, 19, 13, 12, 2, 20, 14, 22, 9, 6, 1
+};
+
+/* update the state with given number of rounds */
+
+static void keccakf(u64 st[25])
+{
+ int i, j, round;
+ u64 t, bc[5];
+
+ for (round = 0; round < KECCAK_ROUNDS; round++) {
+
+ /* Theta */
+ for (i = 0; i < 5; i++)
+ bc[i] = st[i] ^ st[i + 5] ^ st[i + 10] ^ st[i + 15]
+ ^ st[i + 20];
+
+ for (i = 0; i < 5; i++) {
+ t = bc[(i + 4) % 5] ^ ROTL64(bc[(i + 1) % 5], 1);
+ for (j = 0; j < 25; j += 5)
+ st[j + i] ^= t;
+ }
+
+ /* Rho Pi */
+ t = st[1];
+ for (i = 0; i < 24; i++) {
+ j = keccakf_piln[i];
+ bc[0] = st[j];
+ st[j] = ROTL64(t, keccakf_rotc[i]);
+ t = bc[0];
+ }
+
+ /* Chi */
+ for (j = 0; j < 25; j += 5) {
+ for (i = 0; i < 5; i++)
+ bc[i] = st[j + i];
+ for (i = 0; i < 5; i++)
+ st[j + i] ^= (~bc[(i + 1) % 5]) &
+ bc[(i + 2) % 5];
+ }
+
+ /* Iota */
+ st[0] ^= keccakf_rndc[round];
+ }
+}
+
+static void sha3_init(struct sha3_state *sctx, unsigned int digest_sz)
+{
+ memset(sctx, 0, sizeof(*sctx));
+ sctx->md_len = digest_sz;
+ sctx->rsiz = 200 - 2 * digest_sz;
+ sctx->rsizw = sctx->rsiz / 8;
+}
+
+static int sha3_224_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_224_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_256_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_256_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_384_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_384_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_512_init(struct shash_desc *desc)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+
+ sha3_init(sctx, SHA3_512_DIGEST_SIZE);
+ return 0;
+}
+
+static int sha3_update(struct shash_desc *desc, const u8 *data,
+ unsigned int len)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+ unsigned int done;
+ const u8 *src;
+
+ done = 0;
+ src = data;
+
+ if ((sctx->partial + len) > (sctx->rsiz - 1)) {
+ if (sctx->partial) {
+ done = -sctx->partial;
+ memcpy(sctx->buf + sctx->partial, data,
+ done + sctx->rsiz);
+ src = sctx->buf;
+ }
+
+ do {
+ unsigned int i;
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] ^= ((u64 *) src)[i];
+ keccakf(sctx->st);
+
+ done += sctx->rsiz;
+ src = data + done;
+ } while (done + (sctx->rsiz - 1) < len);
+
+ sctx->partial = 0;
+ }
+ memcpy(sctx->buf + sctx->partial, src, len - done);
+ sctx->partial += (len - done);
+
+ return 0;
+}
+
+static int sha3_final(struct shash_desc *desc, u8 *out)
+{
+ struct sha3_state *sctx = shash_desc_ctx(desc);
+ unsigned int i, inlen = sctx->partial;
+
+ sctx->buf[inlen++] = 0x06;
+ memset(sctx->buf + inlen, 0, sctx->rsiz - inlen);
+ sctx->buf[sctx->rsiz - 1] |= 0x80;
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] ^= ((u64 *) sctx->buf)[i];
+
+ keccakf(sctx->st);
+
+ for (i = 0; i < sctx->rsizw; i++)
+ sctx->st[i] = cpu_to_le64(sctx->st[i]);
+
+ memcpy(out, sctx->st, sctx->md_len);
+
+ memset(sctx, 0, sizeof(*sctx));
+ return 0;
+}
+
+static struct shash_alg sha3_224 = {
+ .digestsize = SHA3_224_DIGEST_SIZE,
+ .init = sha3_224_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-224",
+ .cra_driver_name = "sha3-224-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_224_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_256 = {
+ .digestsize = SHA3_256_DIGEST_SIZE,
+ .init = sha3_256_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-256",
+ .cra_driver_name = "sha3-256-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_256_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_384 = {
+ .digestsize = SHA3_384_DIGEST_SIZE,
+ .init = sha3_384_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-384",
+ .cra_driver_name = "sha3-384-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_384_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static struct shash_alg sha3_512 = {
+ .digestsize = SHA3_512_DIGEST_SIZE,
+ .init = sha3_512_init,
+ .update = sha3_update,
+ .final = sha3_final,
+ .descsize = sizeof(struct sha3_state),
+ .base = {
+ .cra_name = "sha3-512",
+ .cra_driver_name = "sha3-512-generic",
+ .cra_flags = CRYPTO_ALG_TYPE_SHASH,
+ .cra_blocksize = SHA3_512_BLOCK_SIZE,
+ .cra_module = THIS_MODULE,
+ }
+};
+
+static int __init sha3_generic_mod_init(void)
+{
+ int ret;
+
+ ret = crypto_register_shash(&sha3_224);
+ if (ret < 0)
+ goto err_out;
+ ret = crypto_register_shash(&sha3_256);
+ if (ret < 0)
+ goto err_out_224;
+ ret = crypto_register_shash(&sha3_384);
+ if (ret < 0)
+ goto err_out_256;
+ ret = crypto_register_shash(&sha3_512);
+ if (ret < 0)
+ goto err_out_384;
+
+ return 0;
+
+err_out_384:
+ crypto_unregister_shash(&sha3_384);
+err_out_256:
+ crypto_unregister_shash(&sha3_256);
+err_out_224:
+ crypto_unregister_shash(&sha3_224);
+err_out:
+ return ret;
+}
+
+static void __exit sha3_generic_mod_fini(void)
+{
+ crypto_unregister_shash(&sha3_224);
+ crypto_unregister_shash(&sha3_256);
+ crypto_unregister_shash(&sha3_384);
+ crypto_unregister_shash(&sha3_512);
+}
+
+module_init(sha3_generic_mod_init);
+module_exit(sha3_generic_mod_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("SHA-3 Secure Hash Algorithm");
+
+MODULE_ALIAS("sha3-224");
+MODULE_ALIAS("sha3-256");
+MODULE_ALIAS("sha3-384");
+MODULE_ALIAS("sha3-512");
diff --git a/include/crypto/sha3.h b/include/crypto/sha3.h
new file mode 100644
index 0000000..f4c9f68
--- /dev/null
+++ b/include/crypto/sha3.h
@@ -0,0 +1,29 @@
+/*
+ * Common values for SHA-3 algorithms
+ */
+#ifndef __CRYPTO_SHA3_H__
+#define __CRYPTO_SHA3_H__
+
+#define SHA3_224_DIGEST_SIZE (224 / 8)
+#define SHA3_224_BLOCK_SIZE (200 - 2 * SHA3_224_DIGEST_SIZE)
+
+#define SHA3_256_DIGEST_SIZE (256 / 8)
+#define SHA3_256_BLOCK_SIZE (200 - 2 * SHA3_256_DIGEST_SIZE)
+
+#define SHA3_384_DIGEST_SIZE (384 / 8)
+#define SHA3_384_BLOCK_SIZE (200 - 2 * SHA3_384_DIGEST_SIZE)
+
+#define SHA3_512_DIGEST_SIZE (512 / 8)
+#define SHA3_512_BLOCK_SIZE (200 - 2 * SHA3_512_DIGEST_SIZE)
+
+struct sha3_state {
+ u64 st[25];
+ unsigned int md_len;
+ unsigned int rsiz;
+ unsigned int rsizw;
+
+ unsigned int partial;
+ u8 buf[SHA3_224_BLOCK_SIZE];
+};
+
+#endif
--
1.9.1
^ permalink raw reply related
* [PATCH 0/2] Add SHA-3 algorithm and test vectors.
From: Raveendra Padasalagi @ 2016-06-15 9:41 UTC (permalink / raw)
To: Herbert Xu, David S. Miller, linux-crypto, linux-kernel
Cc: Jon Mason, Florian Fainelli, Anup Patel, Ray Jui, Scott Branden,
Pramod Kumar, bcm-kernel-feedback-list, Raveendra Padasalagi
This patchset adds the implementation of SHA-3 algorithm
in software and it's based on original implementation
pushed in patch https://lwn.net/Articles/518415/ with
additional changes to match the padding rules specified
in SHA-3 specification.
This patchset also includes changes in tcrypt module to
add support for SHA-3 algorithms test and related test
vectors for basic testing.
Broadcom Secure Processing Unit-2(SPU-2) engine supports
offloading of SHA-3 operations in hardware, in order to
add SHA-3 support in SPU-2 driver we needed to have the
software implementation and test framework in place.
The patchset is based on v4.7-rc1 tag and its tested on
Broadcom NorthStar2 SoC.
Jeff Garzik (1):
Crypto: Add SHA-3 hash algorithm
Raveendra Padasalagi (1):
Crypto: Add SHA-3 Test's in tcrypt
crypto/Kconfig | 10 ++
crypto/Makefile | 1 +
crypto/sha3_generic.c | 296 ++++++++++++++++++++++++++++++++++++++++++++++++++
crypto/tcrypt.c | 53 ++++++++-
crypto/testmgr.c | 40 +++++++
crypto/testmgr.h | 125 +++++++++++++++++++++
include/crypto/sha3.h | 29 +++++
7 files changed, 553 insertions(+), 1 deletion(-)
create mode 100644 crypto/sha3_generic.c
create mode 100644 include/crypto/sha3.h
--
1.9.1
^ permalink raw reply
* Re: [PATCH v8 1/3] crypto: Key-agreement Protocol Primitives API (KPP)
From: Herbert Xu @ 2016-06-15 9:41 UTC (permalink / raw)
To: Benedetto, Salvatore; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <309B30E91F5E2846B79BD9AA9711D031933C15@IRSMSX102.ger.corp.intel.com>
On Tue, Jun 14, 2016 at 02:36:54PM +0000, Benedetto, Salvatore wrote:
>
> My very first patch used PKCS3 and there were some objections to that.
> https://patchwork.kernel.org/patch/8311881/
>
> Both Bluetooth or keyctl KEYCTL_DH_COMPUTE would have to first pack the
> key to whatever format we choose and I don't see that very convinient. We
> only want to provide the acceleration here, without bounding the user to a
> certain key format.
Have you looked at the rtnetlink encoding used by authenc.c? It is
much more light-weight. There is no need to depend on ASN.1 parsers
at all.
To make it even easier for users such as bluetooth, you can create
helpers that convert struct dh to a byte stream, and vice versa.
For example, the interface could look like this:
struct dh key;
char *buf;
unsigned int len;
/* init key */
key = ...;
len = crypto_dh_key_len(&key);
buf = kmalloc(len, GFP_KERNEL);
if (!buf)
...;
crypto_dh_encode_key(buf, len, &key);
crypto_kpp_set_secret(tfm, buf, len);
The driver would do:
set_secret(char *buf, unsigned int len)
{
struct dh key;
int err;
err = crypto_dh_decode_key(buf, len, &key);
...
> akcipher is different as PKCS1 is a recognized standard for RSA keys.
>
> Please don't get me wrong, it's not much of an issue for me to respin the
> patchset and change that to PKCS3 for example, but I see no harm in leaving
> it as it is and moving the key check format to whatever upper layer is using us
> (like BT and keyctl). Just more work for who is using the API.
>
> Could you reconsider that?
I'm sorry but using a void * for this is not acceptable. We're
talking about a data structure that comes from arbitrary users
and then has to be decoded by random drivers. It's something
totally different compared to a limited environment where the
same author is writing the code that creates and consumes the
pointer.
Throwing random void pointers at drivers is not a good idea.
Thanks,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v5] crypto: rsa - return raw integers for the ASN.1 parser
From: Herbert Xu @ 2016-06-15 9:28 UTC (permalink / raw)
To: Tudor Ambarus; +Cc: smueller, linux-crypto
In-Reply-To: <1465910098-16349-1-git-send-email-tudor-dan.ambarus@nxp.com>
On Tue, Jun 14, 2016 at 04:14:58PM +0300, Tudor Ambarus wrote:
> Return the raw key with no other processing so that the caller
> can copy it or MPI parse it, etc.
>
> The scope is to have only one ANS.1 parser for all RSA
> implementations.
>
> Update the RSA software implementation so that it does
> the MPI conversion on top.
>
> Signed-off-by: Tudor Ambarus <tudor-dan.ambarus@nxp.com>
Patch applied. Thanks for persisting with this.
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [PATCH v2 0/4] crypto: CTR DRBG - performance improvements
From: Herbert Xu @ 2016-06-15 9:27 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto
In-Reply-To: <1842774.dgV8IOeQEu@positron.chronox.de>
On Tue, Jun 14, 2016 at 07:33:48AM +0200, Stephan Mueller wrote:
> Hi,
>
> The following patch set is aimed to increase the performance of the CTR
> DRBG, especially when assembler implementations of the CTR AES mode are
> available.
>
> The patch set increases the performance by 10% for random numbers of 16 bytes
> and reaches 450% for random numbers reaching 4096 bytes (larger random
> numbers will even have more performance gains). The performance gains were
> measured when using ctr-aes-aesni.
>
> Note, when using the C implementation of the CTR mode (cipher/ctr.c), the
> performance of the CTR DRBG is slightly worse than it is now, but still it
> is much faster than the Hash or HMAC DRBGs.
>
> The patch set is CAVS tested.
>
> Changes v2:
> * the alignment patch is updated to use the alignment of the underlying TFM
>
> Stephan Mueller (4):
> crypto: CTR DRBG - use CTR AES instead of ECB AES
> crypto: DRBG - use aligned buffers
> crypto: CTR DRBG - use full CTR AES for update
> crypto: CTR DRBG - avoid duplicate maintenance of key
All applied. Thanks!
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-06-15 8:48 UTC (permalink / raw)
To: Herbert Xu
Cc: Jens Axboe, Alasdair G Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), David Miller, Eric Biggers,
Joonsoo Kim, tadeusz.struk, smueller, Masanari Iida, Shaohua Li,
Dan Williams, Martin K. Petersen, Sagi Grimberg, Kent Overstreet,
Keith Busch, Tejun Heo, Ming Lei, Mark Brown, Arnd Bergmann,
linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, LKML
In-Reply-To: <20160615073951.GA14986@gondor.apana.org.au>
On 15 June 2016 at 15:39, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote:
>>
>> But that means we should divide the bulk request into 512-byte size
>> requests and break up the mapped sg table for each request. Another
>> hand we should allocate memory for each request in crypto layer, which
>> dm-crypt have supplied one high efficiency way. I think these are
>> really top level how to use the crypro APIs, does that need to move
>> into crypto laryer? Thanks.
>
> I have already explained to you how you can piggy-back off dm-crypt's
> allocation, so what's the problem?
Because the request created in dm-crypt is connecting with dm-crypt
closely, I am worried if it can work or introduce other issues if we
move these top level things into crypto layer. Anyway I will try to do
that. Thanks.
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Herbert Xu @ 2016-06-15 7:39 UTC (permalink / raw)
To: Baolin Wang
Cc: Jens Axboe, Alasdair G Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), David Miller, Eric Biggers,
Joonsoo Kim, tadeusz.struk, smueller, Masanari Iida, Shaohua Li,
Dan Williams, Martin K. Petersen, Sagi Grimberg, Kent Overstreet,
Keith Busch, Tejun Heo, Ming Lei, Mark Brown, Arnd Bergmann,
linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, LKML
In-Reply-To: <CAMz4ku+s-6MQWHhnaau9fK9ssYJNpS9UFvgASoacP0e3vj-zzg@mail.gmail.com>
On Wed, Jun 15, 2016 at 03:38:02PM +0800, Baolin Wang wrote:
>
> But that means we should divide the bulk request into 512-byte size
> requests and break up the mapped sg table for each request. Another
> hand we should allocate memory for each request in crypto layer, which
> dm-crypt have supplied one high efficiency way. I think these are
> really top level how to use the crypro APIs, does that need to move
> into crypto laryer? Thanks.
I have already explained to you how you can piggy-back off dm-crypt's
allocation, so what's the problem?
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Baolin Wang @ 2016-06-15 7:38 UTC (permalink / raw)
To: Herbert Xu
Cc: Jens Axboe, Alasdair G Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), David Miller, Eric Biggers,
Joonsoo Kim, tadeusz.struk, smueller, Masanari Iida, Shaohua Li,
Dan Williams, Martin K. Petersen, Sagi Grimberg, Kent Overstreet,
Keith Busch, Tejun Heo, Ming Lei, Mark Brown, Arnd Bergmann,
linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, LKML
In-Reply-To: <20160615064939.GA14227@gondor.apana.org.au>
On 15 June 2016 at 14:49, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote:
>>
>> After some investigation, I still think we should divide the bulk
>> request from dm-crypt into small request (each one is 512bytes) if
>> this algorithm is not support bulk mode (like CBC). We have talked
>> with dm-crypt
>> maintainers why dm-crypt always use 512 bytes as one request size in
>> below thread, could you please check it?
>> http://www.kernelhub.org/?p=2&msg=907022
>
> That link only points to an email about an oops.
Ah, sorry. Would you check this thread?
http://lkml.iu.edu/hypermail/linux/kernel/1601.1/03829.html
>
> Diggin through that thread, the only objection I have seen is about
> the fact that you have to generate a fresh IV for each sector, which
> is precisely what I'm suggesting that you do.
>
> IOW, implement the IV generators in the crypto API, and then you can
> easily generate a new IV (if necessary) for each sector.
>
>> That means if we move the IV handling into crypto API, we still can
>> not use bulk interface for all algorithm, for example we still need to
>> read/write with 512 bytes for CBC, you can't use 4k or more block on
>> CBC (and most other encryption modes). If only a part of 4k block is
>> written (and then system crash happens), CBC would corrupt the block
>> completely. It means if we map one whole bio with bulk interface in
>> dm-crypt, we need to divide into every 512 bytes requests in crypto
>> layer. So I don't think we can handle every algorithm with bulk
>> interface just moving the IV handling into crypto API. Thanks.
>
> Of course you would do CBC in 512-byte blocks, but my point is that
> you should do this in a crypto API algorithm, rather than dm-crypt
> as we do now. Once you implement that then dm-crypt can treat
> every algorithm as if they supported bulk processing.
But that means we should divide the bulk request into 512-byte size
requests and break up the mapped sg table for each request. Another
hand we should allocate memory for each request in crypto layer, which
dm-crypt have supplied one high efficiency way. I think these are
really top level how to use the crypro APIs, does that need to move
into crypto laryer? Thanks.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
Baolin.wang
Best Regards
^ permalink raw reply
* Re: [PATCH v6 3/6] crypto: AF_ALG -- add asymmetric cipher interface
From: Stephan Mueller @ 2016-06-15 7:04 UTC (permalink / raw)
To: Mat Martineau
Cc: Tadeusz Struk, dhowells, herbert, linux-api, marcel, linux-kernel,
keyrings, linux-crypto, dwmw2, davem
In-Reply-To: <alpine.OSX.2.20.1606140952080.13500@animeshb-mobl.amr.corp.intel.com>
Am Dienstag, 14. Juni 2016, 10:22:15 schrieb Mat Martineau:
Hi Mat,
> Stephan,
>
> On Sat, 14 May 2016, Tadeusz Struk wrote:
> > From: Stephan Mueller <smueller@chronox.de>
> >
> > This patch adds the user space interface for asymmetric ciphers. The
> > interface allows the use of sendmsg as well as vmsplice to provide data.
> >
> > This version has been rebased on top of 4.6 and a few chackpatch issues
> > have been fixed.
> >
> > Signed-off-by: Stephan Mueller <smueller@chronox.de>
> > Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
> > ---
> > crypto/algif_akcipher.c | 542
> > +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 542
> > insertions(+)
> > create mode 100644 crypto/algif_akcipher.c
> >
> > diff --git a/crypto/algif_akcipher.c b/crypto/algif_akcipher.c
> > new file mode 100644
> > index 0000000..6342b6e
> > --- /dev/null
> > +++ b/crypto/algif_akcipher.c
> > +
> > +static int akcipher_sendmsg(struct socket *sock, struct msghdr *msg,
> > + size_t size)
> > +{
> > + struct sock *sk = sock->sk;
> > + struct alg_sock *ask = alg_sk(sk);
> > + struct akcipher_ctx *ctx = ask->private;
> > + struct akcipher_sg_list *sgl = &ctx->tsgl;
> > + struct af_alg_control con = {};
> > + long copied = 0;
> > + int op = 0;
> > + bool init = 0;
> > + int err;
> > +
> > + if (msg->msg_controllen) {
> > + err = af_alg_cmsg_send(msg, &con);
> > + if (err)
> > + return err;
> > +
> > + init = 1;
> > + switch (con.op) {
> > + case ALG_OP_VERIFY:
> > + case ALG_OP_SIGN:
> > + case ALG_OP_ENCRYPT:
> > + case ALG_OP_DECRYPT:
> > + op = con.op;
> > + break;
> > + default:
> > + return -EINVAL;
> > + }
> > + }
> > +
> > + lock_sock(sk);
> > + if (!ctx->more && ctx->used)
> > + goto unlock;
>
> err might be uninitialised at this goto. Should it be set to something
> like -EALREADY to indicate that data is already queued for a different
> crypto op?
Thanks for the hint. Tadeusz, I will provide you with an updated
algif_akcipher.c for your patchset.
I will also have a look at the comment from Andrew.
>
> <snip>
>
> > +unlock:
> > + akcipher_data_wakeup(sk);
> > + release_sock(sk);
> > +
> > + return err ?: copied;
> > +}
>
> Regards,
>
> --
> Mat Martineau
> Intel OTC
Ciao
Stephan
^ permalink raw reply
* Re: [RFC v4 2/4] crypto: Introduce CRYPTO_ALG_BULK flag
From: Herbert Xu @ 2016-06-15 6:49 UTC (permalink / raw)
To: Baolin Wang
Cc: Jens Axboe, Alasdair G Kergon, Mike Snitzer,
open list:DEVICE-MAPPER (LVM), David Miller, Eric Biggers,
Joonsoo Kim, tadeusz.struk, smueller, Masanari Iida, Shaohua Li,
Dan Williams, Martin K. Petersen, Sagi Grimberg, Kent Overstreet,
Keith Busch, Tejun Heo, Ming Lei, Mark Brown, Arnd Bergmann,
linux-crypto, linux-block,
open list:SOFTWARE RAID (Multiple Disks) SUPPORT, LKML
In-Reply-To: <CAMz4kuKXJ5xUXj111VBb9hMH=kT3Y5P3_iVtgeS8kidbLZ+6TA@mail.gmail.com>
On Wed, Jun 15, 2016 at 02:27:04PM +0800, Baolin Wang wrote:
>
> After some investigation, I still think we should divide the bulk
> request from dm-crypt into small request (each one is 512bytes) if
> this algorithm is not support bulk mode (like CBC). We have talked
> with dm-crypt
> maintainers why dm-crypt always use 512 bytes as one request size in
> below thread, could you please check it?
> http://www.kernelhub.org/?p=2&msg=907022
That link only points to an email about an oops.
Diggin through that thread, the only objection I have seen is about
the fact that you have to generate a fresh IV for each sector, which
is precisely what I'm suggesting that you do.
IOW, implement the IV generators in the crypto API, and then you can
easily generate a new IV (if necessary) for each sector.
> That means if we move the IV handling into crypto API, we still can
> not use bulk interface for all algorithm, for example we still need to
> read/write with 512 bytes for CBC, you can't use 4k or more block on
> CBC (and most other encryption modes). If only a part of 4k block is
> written (and then system crash happens), CBC would corrupt the block
> completely. It means if we map one whole bio with bulk interface in
> dm-crypt, we need to divide into every 512 bytes requests in crypto
> layer. So I don't think we can handle every algorithm with bulk
> interface just moving the IV handling into crypto API. Thanks.
Of course you would do CBC in 512-byte blocks, but my point is that
you should do this in a crypto API algorithm, rather than dm-crypt
as we do now. Once you implement that then dm-crypt can treat
every algorithm as if they supported bulk processing.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox