* [PATCH v6 0/5] /dev/random - a new approach
From: Stephan Mueller @ 2016-08-11 12:24 UTC (permalink / raw)
To: herbert, Ted Tso
Cc: sandyinchina, Jason Cooper, John Denker, H. Peter Anvin,
Joe Perches, Pavel Machek, George Spelvin, linux-crypto,
linux-kernel
Hi Herbert, Ted,
The following patch set provides a different approach to /dev/random which
I call Linux Random Number Generator (LRNG) to collect entropy within the Linux
kernel. The main improvements compared to the legacy /dev/random is to provide
sufficient entropy during boot time as well as in virtual environments and when
using SSDs. A secondary design goal is to limit the impact of the entropy
collection on massive parallel systems and also allow the use accelerated
cryptographic primitives. Also, all steps of the entropic data processing are
testable. Finally massive performance improvements are visible at /dev/urandom
and get_random_bytes.
The design and implementation is driven by a set of goals described in [1]
that the LRNG completely implements. Furthermore, [1] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.
Changes v6:
* port to 4.8-rc1
* add missing memzero_explicit to ChaCha20 DRNG
* use kernel-doc documentation style
* use of min3 in lrng_get_pool to beautify code
* prevent fast noise sources from dominating slow noise sources
in case of /dev/random
* set read wakeup threshold to 64 bits to comply with legacy /dev/random
* simplify the interrupt to entropy amount conversion code
* move wakeup call of entropy-providers to a code location where /dev/urandom
will benefit from the wake up as well (i.e. when the primary DRBG entropy
runs low because of /dev/urandom reseeds, the entropy provider is woken up)
* inject current time into primary DRBG at the time of seeding from noise
sources (suggested by Sandy Harris)
Changes v5:
* fix treating LRNG_POOL_SIZE_BITS as entropy value in lrng_get_pool
* use CTR DRBG with AES256 as default due to its superior speed -- on X86_64
executing within a KVM I get read speeds of up to 850 MB/s now. When using a
fake NUMA system with 4 nodes on 4 CPUs, I still get up to 430 MB/s read speed
with four parallel reads. Note, this patch applies to the current
cryptodev-2.6 tree.
* simplify lrng_get_arch
* use DRBG security strengths as defined in SP800-57 section 5.6.1
* add security strength to /proc/sys/kernel/random/lrng_type
* add ChaCha20 DRNG: in case the kernel crypto API is not compiled, the ChaCha20
DRNG with the SHA-1 C implementations are used to drive the cryptographic part
of the LRNG.The ChaCha20 RNG is described in [1]. I analyzed it with a user
space version of it.
* Editorial changes requested by checkpatch.pl
Changes v4:
* port to 4.7-rc1
* Use classical twisted LFSR approach to collect entropic data as requested by
George Spelvin. The LFSR is based on a primitive and irreducible polynomial
whose taps are not too close to the location the current byte is mixed in.
Primitive polynomials for other entropy pool sizes are offered in the code.
* The reading of the entropy pool is performed with a hash. The hash can be
specified at compile time. The pre-defined hashes are the same as used for
the DRBG type (e.g. a SHA256 Hash DRBG implies the use of SHA-256, an AES256
CTR DRBG implies the use of CMAC-AES).
* Addition of the example defines for a CTR DRBG with AES128 which can be
enabled during compile time.
* Entropy estimate: one bit of entropy per interrupt. In case a system does
not have a high-resolution timer, apply 1/10th bit of entropy per interrupt.
The interrupt estimates can be changed arbitrarily at compile time.
* Use kmalloc_node for the per-NUMA node secondary DRBGs.
* Add boot time entropy tests discussed in section 3.4.3 [1].
* Align all buffers that are processed by the kernel crypto API to an 8 byte
boundary. This boundary covers all currently existing cipher implementations.
Changes v3:
* Convert debug printk to pr_debug as suggested by Joe Perches
* Add missing \n as suggested by Joe Perches
* Do not mix in struck IRQ measurements as requested by Pavel Machek
* Add handling logic for systems without high-res timer as suggested by Pavel
Machek -- it uses ideas from the add_interrupt_randomness of the legacy
/dev/random implementation
* add per NUMA node secondary DRBGs as suggested by Andi Kleen -- the
explanation of how the logic works is given in section 2.1.1 of my
documentation [1], especially how the initial seeding is performed.
Changes v2:
* Removal of the Jitter RNG fast noise source as requested by Ted
* Addition of processing of add_input_randomness as suggested by Ted
* Update documentation and testing in [1] to cover the updates
* Addition of a SystemTap script to test add_input_randomness
* To clarify the question whether sufficient entropy is present during boot
I added one more test in 3.3.1 [1] which demonstrates the providing of
sufficient entropy during initialization. In the worst case of no fast noise
sources, in the worst case of a virtual machine with only very few hardware
devices, the testing shows that the secondary DRBG is fully seeded with 256
bits of entropy before user space injects the random data obtained
during shutdown of the previous boot (i.e. the requirement phrased by the
legacy /dev/random implementation). As the writing of the random data into
/dev/random by user space will happen before any cryptographic service
is initialized in user space, this test demonstrates that sufficient
entropy is already present in the LRNG at the time user space requires it
for seeding cryptographic daemons. Note, this test result was obtained
for different architectures, such as x86 64 bit, x86 32 bit, ARM 32 bit and
MIPS 32 bit.
[1] http://www.chronox.de/lrng/doc/lrng.pdf
[2] http://www.chronox.de/lrng.html
Stephan Mueller (5):
crypto: DRBG - externalize DRBG functions for LRNG
random: conditionally compile code depending on LRNG
crypto: Linux Random Number Generator
crypto: LRNG - enable compile
crypto: LRNG - add ChaCha20 support
crypto/Kconfig | 10 +
crypto/Makefile | 7 +
crypto/drbg.c | 11 +-
crypto/lrng_base.c | 1960 ++++++++++++++++++++++++++++++++++++++++++++++
crypto/lrng_kcapi.c | 167 ++++
crypto/lrng_standalone.c | 220 ++++++
drivers/char/random.c | 8 +
include/crypto/drbg.h | 7 +
include/linux/genhd.h | 5 +
include/linux/random.h | 7 +-
10 files changed, 2395 insertions(+), 7 deletions(-)
create mode 100644 crypto/lrng_base.c
create mode 100644 crypto/lrng_kcapi.c
create mode 100644 crypto/lrng_standalone.c
--
2.7.4
^ permalink raw reply
* [PATCH] X.509: Fix double free in x509_cert_parse().
From: Artem Savkov @ 2016-08-11 12:18 UTC (permalink / raw)
To: tadeusz.struk; +Cc: dhowells, linux-crypto, linux-kernel, Artem Savkov
Patch "crypto: KEYS: convert public key and digsig asym to the akcipher
api" introduced double freeing of cert->pub->key. There is no need to free
it in error_decode label as it is later freed in x509_free_certificate().
Signed-off-by: Artem Savkov <asavkov@redhat.com>
---
crypto/asymmetric_keys/x509_cert_parser.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
index 1f1899d..9157071 100644
--- a/crypto/asymmetric_keys/x509_cert_parser.c
+++ b/crypto/asymmetric_keys/x509_cert_parser.c
@@ -133,7 +133,6 @@ struct x509_certificate *x509_cert_parse(const void *data, size_t datalen)
return cert;
error_decode:
- kfree(cert->pub->key);
kfree(ctx);
error_no_ctx:
x509_free_certificate(cert);
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: miaoqing @ 2016-08-11 2:54 UTC (permalink / raw)
To: Jason Cooper
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall,
Valo, Kalle, linux-wireless, ath9k-devel, linux-crypto,
Sepehrdad, Pouyan
In-Reply-To: <20160810132449.GH2013@io.lakedaemon.net>
Hi Jason,
On 2016-08-10 21:24, Jason Cooper wrote:
> *gentle reminder: others are reading which may not be directly included
> in the conversation. Including the archives. Please avoid top
> posting.
> :)
Thanks:)
> The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> the appropriate place for it. It's not a devicetree blob, mac address,
> or pci config space. Which are things we feed in once for the heck of
> it. This is a *continuous* source or questionable quality.
>
> I'm seriously considering putting this and timeriomem-rng into a
> subdirectory under hw_random/, maybe environ/. Anything in there gets
> quality=0 for default, and *doesn't* contribute to /dev/hwrng.
>
> Regardless which path we take, I think we should include 'adc' in the
> name. I've heard countless times about "Atheros cards come with an rng
> on board". :-/
If I understand correctly, you want to bind the ADC source to
/dev/hwrng,
and then change rng-tools to set the entropy to zero in the ioctl call ?
There are two major problems with that approach,
1) We already tried once before to bind our solution to /dev/hwrng, and
got
so much complaints. The conclusion was that maybe we know that the
output of
/dev/hwrng does not have perfect entropy, but a normal user does not
know and
will misuse it. You mentioned in
https://www.kernel.org/doc/Documentation/hw_random.txt
we have
"This data is NOT CHECKED by any
fitness tests, and could potentially be bogus (if the
hardware is faulty or has been tampered with). Data is only
output if the hardware "has-data" flag is set, but nevertheless
a security-conscious person would run fitness tests on the
data before assuming it is truly random."
But this is not enough to convince upstream to switch to /dev/hwrng. I
think the
concern of users misusing the solution is a very valid concern.
2) If we set the entropy to zero in rng-tools, we cannot tolerate the
load.
Rng-tools is not a timer-based solution. Similar to our solution, it is
based on
/proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
the entropy
counter, rng-tools keep writing into the pool, and both rng-tools and
WiFi chip will
be overloaded.
Thanks,
Miaoqing
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Theodore Ts'o @ 2016-08-10 23:44 UTC (permalink / raw)
To: Jason Cooper
Cc: Pan, Miaoqing, Stephan Mueller, Sepehrdad, Pouyan,
herbert@gondor.apana.org.au, linux-kernel@vger.kernel.org,
linux-crypto@vger.kernel.org, ath9k-devel,
linux-wireless@vger.kernel.org, ath9k-devel@lists.ath9k.org,
Kalle Valo
In-Reply-To: <20160809140444.GB2013@io.lakedaemon.net>
On Tue, Aug 09, 2016 at 02:04:44PM +0000, Jason Cooper wrote:
>
> iiuc, Ted, you're saying using the hw_random framework would be
> disasterous because despite most drivers having a default quality of 0,
> rngd assumes 1 bit of entropy for every bit read?
Sorry, what I was trying to say (but failed) was that bypassing the
hwrng framework and injecting entropy directly the entropy pool was
disatrous.
> Thankfully, most hw_random drivers don't set the quality. So unless the
> user sets the default_quality param, it's zero.
The fact that this is "most" and not "all" does scare me a little.
As far as I'm concerned *all* hw_random drivers should set quality to
zero, since it should be up to the system administrator. Perhaps the
one exception is virtio_rng, since if you don't trust the hypvervisor,
the security of the VM is hopeless. That being said, I have seen
configurations of KVM which use:
-object rng-random,filename=/dev/urandom,id=rng0 \
-device virtio-rng-pci,rng=rng0
Which is somewhat non-ideal. (Try running od -x /dev/random on such a
guest system....)
- Ted
^ permalink raw reply
* Re: [PATCH] crypto: XTS - remove test that will fail in FIPS mode
From: Tapas Sarangi @ 2016-08-10 22:08 UTC (permalink / raw)
To: Stephan Mueller, herbert@gondor.apana.org.au; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <3590892.3HIz2aNZPY@positron.chronox.de>
Hi Stephan,
Thanks. Sorry for a late reply to this.
I did test your patch for testmgr.h with the vanilla kernel 4.7 source.
This doesn¹t solve the xts(aes) self-test failure in FIPS mode. I get the
exact same error as before.
Thanks
-Tapas
On 8/10/16, 12:49 AM, "Stephan Mueller" <smueller@chronox.de> wrote:
>Hi Tapas, Herbert,
>
>Tapas: this patch should fix it. Can you please test?
>
>Herbert: The reason why I have to caught this issue in my tests is the
>following: I compile xts-aes-aesni statically as you can see below. The
>self test is marked as passed, although there is no XTS test performed.
>When you boot in FIPS mode, the testmgr prints out all tests. But XTS is
>not among them. Do you have an idea why that happens?
>
>name : xts(aes)
>driver : xts-aes-aesni
>module : kernel
>priority : 400
>refcnt : 1
>selftest : passed
>internal : no
>type : ablkcipher
>async : yes
>blocksize : 16
>min keysize : 32
>max keysize : 64
>ivsize : 16
>geniv : <default>
>
>---8<---
>
>In FIPS mode, setting XTS keys where the AES key is identical to the
>tweak key is forbidden. Thus, the self test with such property will fail
>in FIPS mode.
>
>As we have other tests available for XTS, this patch simply removes the
>offending test vectors.
>
>Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
>Signed-off-by: Stephan Mueller <smueller@chronox.de>
>---
> crypto/testmgr.h | 36 ------------------------------------
> 1 file changed, 36 deletions(-)
>
>diff --git a/crypto/testmgr.h b/crypto/testmgr.h
>index acb6bbf..e4b58f5 100644
>--- a/crypto/testmgr.h
>+++ b/crypto/testmgr.h
>@@ -10179,24 +10179,6 @@ static struct cipher_testvec
>tf_lrw_dec_tv_template[] = {
> static struct cipher_testvec tf_xts_enc_tv_template[] = {
> /* Generated from AES-XTS test vectors */
> {
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .ilen = 32,
>- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>- .rlen = 32,
>- }, {
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>@@ -10522,24 +10504,6 @@ static struct cipher_testvec
>tf_xts_dec_tv_template[] = {
> /* Generated from AES-XTS test vectors */
> /* same as enc vectors with input and result reversed */
> {
>- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .klen = 32,
>- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .input = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
>- "\x30\x74\xe4\x44\x52\x77\x97\x43"
>- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
>- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
>- .ilen = 32,
>- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00"
>- "\x00\x00\x00\x00\x00\x00\x00\x00",
>- .rlen = 32,
>- }, {
> .key = "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x11\x11\x11\x11\x11\x11\x11\x11"
> "\x22\x22\x22\x22\x22\x22\x22\x22"
>--
>2.7.4
>
>
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* [PATCH] crypto: CCP - build error: label 'e_hwrng' undefined
From: Gary R Hook @ 2016-08-10 17:45 UTC (permalink / raw)
To: linux-crypto; +Cc: thomas.lendacky, gary.hook, herbert, davem
Fix goto target for when registration fails
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Gary R Hook <gary.hook@amd.com>
---
drivers/crypto/ccp/ccp-dev-v5.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-dev-v5.c b/drivers/crypto/ccp/ccp-dev-v5.c
index 4086714..114675e 100644
--- a/drivers/crypto/ccp/ccp-dev-v5.c
+++ b/drivers/crypto/ccp/ccp-dev-v5.c
@@ -835,7 +835,7 @@ static int ccp5_init(struct ccp_device *ccp)
/* Register the DMA engine support */
ret = ccp_dmaengine_register(ccp);
if (ret)
- goto e_hwrng;
+ goto e_kthread;
return 0;
^ permalink raw reply related
* [PATCH 6/6] crypto: sun4i-ss: fix indentation of two crypto alg
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
Two crypto alg are badly indented, this patch fix this style issue.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-core.c | 68 ++++++++++++++++-----------------
1 file changed, 34 insertions(+), 34 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-core.c b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
index 107cd2a..3ac6c6c 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-core.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-core.c
@@ -172,45 +172,45 @@ static struct sun4i_ss_alg_template ss_algs[] = {
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
- .cra_name = "cbc(des3_ede)",
- .cra_driver_name = "cbc-des3-sun4i-ss",
- .cra_priority = 300,
- .cra_blocksize = DES3_EDE_BLOCK_SIZE,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
- .cra_ctxsize = sizeof(struct sun4i_req_ctx),
- .cra_module = THIS_MODULE,
- .cra_alignmask = 3,
- .cra_type = &crypto_ablkcipher_type,
- .cra_init = sun4i_ss_cipher_init,
- .cra_u.ablkcipher = {
- .min_keysize = DES3_EDE_KEY_SIZE,
- .max_keysize = DES3_EDE_KEY_SIZE,
- .ivsize = DES3_EDE_BLOCK_SIZE,
- .setkey = sun4i_ss_des3_setkey,
- .encrypt = sun4i_ss_cbc_des3_encrypt,
- .decrypt = sun4i_ss_cbc_des3_decrypt,
+ .cra_name = "cbc(des3_ede)",
+ .cra_driver_name = "cbc-des3-sun4i-ss",
+ .cra_priority = 300,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .cra_ctxsize = sizeof(struct sun4i_req_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
+ .cra_type = &crypto_ablkcipher_type,
+ .cra_init = sun4i_ss_cipher_init,
+ .cra_u.ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = sun4i_ss_des3_setkey,
+ .encrypt = sun4i_ss_cbc_des3_encrypt,
+ .decrypt = sun4i_ss_cbc_des3_decrypt,
}
}
},
{ .type = CRYPTO_ALG_TYPE_ABLKCIPHER,
.alg.crypto = {
- .cra_name = "ecb(des3_ede)",
- .cra_driver_name = "ecb-des3-sun4i-ss",
- .cra_priority = 300,
- .cra_blocksize = DES3_EDE_BLOCK_SIZE,
- .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
- .cra_ctxsize = sizeof(struct sun4i_req_ctx),
- .cra_module = THIS_MODULE,
- .cra_alignmask = 3,
- .cra_type = &crypto_ablkcipher_type,
- .cra_init = sun4i_ss_cipher_init,
- .cra_u.ablkcipher = {
- .min_keysize = DES3_EDE_KEY_SIZE,
- .max_keysize = DES3_EDE_KEY_SIZE,
- .ivsize = DES3_EDE_BLOCK_SIZE,
- .setkey = sun4i_ss_des3_setkey,
- .encrypt = sun4i_ss_ecb_des3_encrypt,
- .decrypt = sun4i_ss_ecb_des3_decrypt,
+ .cra_name = "ecb(des3_ede)",
+ .cra_driver_name = "ecb-des3-sun4i-ss",
+ .cra_priority = 300,
+ .cra_blocksize = DES3_EDE_BLOCK_SIZE,
+ .cra_flags = CRYPTO_ALG_TYPE_ABLKCIPHER,
+ .cra_ctxsize = sizeof(struct sun4i_req_ctx),
+ .cra_module = THIS_MODULE,
+ .cra_alignmask = 3,
+ .cra_type = &crypto_ablkcipher_type,
+ .cra_init = sun4i_ss_cipher_init,
+ .cra_u.ablkcipher = {
+ .min_keysize = DES3_EDE_KEY_SIZE,
+ .max_keysize = DES3_EDE_KEY_SIZE,
+ .ivsize = DES3_EDE_BLOCK_SIZE,
+ .setkey = sun4i_ss_des3_setkey,
+ .encrypt = sun4i_ss_ecb_des3_encrypt,
+ .decrypt = sun4i_ss_ecb_des3_decrypt,
}
}
},
--
2.7.3
^ permalink raw reply related
* [cryptodev:master 17/45] drivers/crypto/ccp/ccp-dev-v5.c:838:3: error: label 'e_hwrng' used but not defined
From: kbuild test robot @ 2016-08-10 15:30 UTC (permalink / raw)
To: Gary R Hook; +Cc: kbuild-all, linux-crypto, Herbert Xu
[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
head: 47856204146ba6fd0f198dbb23c4ed7ad1c3fd99
commit: 99d90b2ebd8b327c0c496798db99009b30c70945 [17/45] crypto: ccp - Enable DMA service on a v5 CCP
config: i386-randconfig-h1-08102150 (attached as .config)
compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
git checkout 99d90b2ebd8b327c0c496798db99009b30c70945
# save the attached .config to linux build tree
make ARCH=i386
Note: the cryptodev/master HEAD 47856204146ba6fd0f198dbb23c4ed7ad1c3fd99 builds fine.
It only hurts bisectibility.
All errors (new ones prefixed by >>):
drivers/crypto/ccp/ccp-dev-v5.c: In function 'ccp5_init':
>> drivers/crypto/ccp/ccp-dev-v5.c:838:3: error: label 'e_hwrng' used but not defined
goto e_hwrng;
^~~~
vim +/e_hwrng +838 drivers/crypto/ccp/ccp-dev-v5.c
832 if (ret)
833 goto e_kthread;
834
835 /* Register the DMA engine support */
836 ret = ccp_dmaengine_register(ccp);
837 if (ret)
> 838 goto e_hwrng;
839
840 return 0;
841
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/octet-stream, Size: 27609 bytes --]
^ permalink raw reply
* [PATCH] crypto: XTS - remove test that will fail in FIPS mode
From: Stephan Mueller @ 2016-08-10 5:49 UTC (permalink / raw)
To: Tapas Sarangi, herbert@gondor.apana.org.au; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CFBBE7.2B1D%tsarangi@trustwave.com>
Hi Tapas, Herbert,
Tapas: this patch should fix it. Can you please test?
Herbert: The reason why I have to caught this issue in my tests is the following: I compile xts-aes-aesni statically as you can see below. The self test is marked as passed, although there is no XTS test performed. When you boot in FIPS mode, the testmgr prints out all tests. But XTS is not among them. Do you have an idea why that happens?
name : xts(aes)
driver : xts-aes-aesni
module : kernel
priority : 400
refcnt : 1
selftest : passed
internal : no
type : ablkcipher
async : yes
blocksize : 16
min keysize : 32
max keysize : 64
ivsize : 16
geniv : <default>
---8<---
In FIPS mode, setting XTS keys where the AES key is identical to the
tweak key is forbidden. Thus, the self test with such property will fail
in FIPS mode.
As we have other tests available for XTS, this patch simply removes the
offending test vectors.
Reported-by: Tapas Sarangi <TSarangi@trustwave.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
crypto/testmgr.h | 36 ------------------------------------
1 file changed, 36 deletions(-)
diff --git a/crypto/testmgr.h b/crypto/testmgr.h
index acb6bbf..e4b58f5 100644
--- a/crypto/testmgr.h
+++ b/crypto/testmgr.h
@@ -10179,24 +10179,6 @@ static struct cipher_testvec tf_lrw_dec_tv_template[] = {
static struct cipher_testvec tf_xts_enc_tv_template[] = {
/* Generated from AES-XTS test vectors */
{
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .ilen = 32,
- .result = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
- "\x30\x74\xe4\x44\x52\x77\x97\x43"
- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
- .rlen = 32,
- }, {
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
@@ -10522,24 +10504,6 @@ static struct cipher_testvec tf_xts_dec_tv_template[] = {
/* Generated from AES-XTS test vectors */
/* same as enc vectors with input and result reversed */
{
- .key = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .klen = 32,
- .iv = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .input = "\x4b\xc9\x44\x4a\x11\xa3\xef\xac"
- "\x30\x74\xe4\x44\x52\x77\x97\x43"
- "\xa7\x60\xb2\x45\x2e\xf9\x00\x90"
- "\x9f\xaa\xfd\x89\x6e\x9d\x4a\xe0",
- .ilen = 32,
- .result = "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00"
- "\x00\x00\x00\x00\x00\x00\x00\x00",
- .rlen = 32,
- }, {
.key = "\x11\x11\x11\x11\x11\x11\x11\x11"
"\x11\x11\x11\x11\x11\x11\x11\x11"
"\x22\x22\x22\x22\x22\x22\x22\x22"
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 6:51 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <82844e4b56c9475fabf22b3fe12b53bb@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply
* [PATCH 3/6] crypto: sun4i-ss: clean unused ss
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
The ss variable is never used, remove it.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 2fb0684..7841d73 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -32,12 +32,10 @@ int sun4i_hash_init(struct ahash_request *areq)
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
struct ahash_alg *alg = __crypto_ahash_alg(tfm->base.__crt_alg);
struct sun4i_ss_alg_template *algt;
- struct sun4i_ss_ctx *ss;
memset(op, 0, sizeof(struct sun4i_req_ctx));
algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
- ss = algt->ss;
op->ss = algt->ss;
op->mode = algt->mode;
--
2.7.3
^ permalink raw reply related
* [PATCH 1/6] crypto: sun4i-ss: fix a few signed warning
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
The variable i is always checked against unsigned value and cannot be
negative.
This patch set it as unsigned.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
index 3830d7c..90efd10 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-cipher.c
@@ -29,7 +29,8 @@ static int sun4i_ss_opti_poll(struct ablkcipher_request *areq)
u32 tx_cnt = 0;
u32 spaces;
u32 v;
- int i, err = 0;
+ int err = 0;
+ unsigned int i;
unsigned int ileft = areq->nbytes;
unsigned int oleft = areq->nbytes;
unsigned int todo;
@@ -139,7 +140,8 @@ static int sun4i_ss_cipher_poll(struct ablkcipher_request *areq)
u32 tx_cnt = 0;
u32 v;
u32 spaces;
- int i, err = 0;
+ int err = 0;
+ unsigned int i;
unsigned int ileft = areq->nbytes;
unsigned int oleft = areq->nbytes;
unsigned int todo;
--
2.7.3
^ permalink raw reply related
* Re: [cryptodev:master 17/45] drivers/crypto/ccp/ccp-dev-v5.c:838:3: error: label 'e_hwrng' used but not defined
From: Gary R Hook @ 2016-08-10 16:48 UTC (permalink / raw)
To: linux-crypto; +Cc: Herbert Xu
In-Reply-To: <201608102355.WhiXil4y%fengguang.wu@intel.com>
A patch for this will be submitted shortly.
On 08/10/2016 10:30 AM, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
> head: 47856204146ba6fd0f198dbb23c4ed7ad1c3fd99
> commit: 99d90b2ebd8b327c0c496798db99009b30c70945 [17/45] crypto: ccp - Enable DMA service on a v5 CCP
> config: i386-randconfig-h1-08102150 (attached as .config)
> compiler: gcc-6 (Debian 6.1.1-9) 6.1.1 20160705
> reproduce:
> git checkout 99d90b2ebd8b327c0c496798db99009b30c70945
> # save the attached .config to linux build tree
> make ARCH=i386
>
> Note: the cryptodev/master HEAD 47856204146ba6fd0f198dbb23c4ed7ad1c3fd99 builds fine.
> It only hurts bisectibility.
>
> All errors (new ones prefixed by >>):
>
> drivers/crypto/ccp/ccp-dev-v5.c: In function 'ccp5_init':
>>> drivers/crypto/ccp/ccp-dev-v5.c:838:3: error: label 'e_hwrng' used but not defined
> goto e_hwrng;
> ^~~~
>
> vim +/e_hwrng +838 drivers/crypto/ccp/ccp-dev-v5.c
>
> 832 if (ret)
> 833 goto e_kthread;
> 834
> 835 /* Register the DMA engine support */
> 836 ret = ccp_dmaengine_register(ccp);
> 837 if (ret)
> > 838 goto e_hwrng;
> 839
> 840 return 0;
> 841
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
>
^ permalink raw reply
* [PATCH v4] KEYS: add SP800-56A KDF support for DH
From: Stephan Mueller @ 2016-08-10 5:15 UTC (permalink / raw)
To: Mat Martineau; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1608091546100.24354@mjmartin-mac01.local>
SP800-56A defines the use of DH with key derivation function based on a
counter. The input to the KDF is defined as (DH shared secret || other
information). The value for the "other information" is to be provided by
the caller.
The KDF is provided by the kernel crypto API. The SP800-56A KDF is equal
to the SP800-108 counter KDF. However, the caller is allowed to specify
the KDF type that he wants to use to derive the key material allowing
the use of the other KDFs provided with the kernel crypto API.
As the KDF implements the proper truncation of the DH shared secret to
the requested size, this patch fills the caller buffer up to its size.
The patch is tested with a new test added to the keyutils user space
code which uses a CAVS test vector testing the compliance with
SP800-56A.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
Documentation/security/keys.txt | 35 ++++++++++---
include/linux/compat.h | 7 +++
include/uapi/linux/keyctl.h | 7 +++
security/keys/Kconfig | 1 +
security/keys/Makefile | 3 +-
security/keys/compat.c | 5 +-
security/keys/compat_dh.c | 36 +++++++++++++
security/keys/dh.c | 110 +++++++++++++++++++++++++++++++++++-----
security/keys/internal.h | 21 +++++++-
security/keys/keyctl.c | 2 +-
10 files changed, 201 insertions(+), 26 deletions(-)
create mode 100644 security/keys/compat_dh.c
diff --git a/Documentation/security/keys.txt b/Documentation/security/keys.txt
index 3849814..9df0605 100644
--- a/Documentation/security/keys.txt
+++ b/Documentation/security/keys.txt
@@ -827,7 +827,7 @@ The keyctl syscall functions are:
long keyctl(KEYCTL_DH_COMPUTE, struct keyctl_dh_params *params,
char *buffer, size_t buflen,
- void *reserved);
+ struct keyctl_kdf_params *kdf);
The params struct contains serial numbers for three keys:
@@ -844,18 +844,37 @@ The keyctl syscall functions are:
public key. If the base is the remote public key, the result is
the shared secret.
- The reserved argument must be set to NULL.
+ If the parameter kdf is NULL, the following applies:
- The buffer length must be at least the length of the prime, or zero.
+ - The buffer length must be at least the length of the prime, or zero.
- If the buffer length is nonzero, the length of the result is
- returned when it is successfully calculated and copied in to the
- buffer. When the buffer length is zero, the minimum required
- buffer length is returned.
+ - If the buffer length is nonzero, the length of the result is
+ returned when it is successfully calculated and copied in to the
+ buffer. When the buffer length is zero, the minimum required
+ buffer length is returned.
+
+ The kdf parameter allows the caller to apply a key derivation function
+ (KDF) on the Diffie-Hellman computation where only the result
+ of the KDF is returned to the caller. The KDF is characterized with
+ struct keyctl_kdf_params as follows:
+
+ - char *kdfname specifies the NUL terminated string identifying
+ the KDF function used from the kernel crypto API. As of now,
+ only non-keyed KDFs are supported, such as kdf_ctr(sha256),
+ kdf_fb(sha1) or kdf_dpi(sha512). The use of kdf_ctr() complies
+ with SP800-56A.
+
+ - char *otherinfo specifies the OtherInfo data as documented in
+ SP800-56A section 5.8.1.2. The length of the buffer is given with
+ otherinfolen. The format of OtherInfo is defined by the caller.
+ The otherinfo pointer may be NULL if no OtherInfo shall be used.
This function will return error EOPNOTSUPP if the key type is not
supported, error ENOKEY if the key could not be found, or error
- EACCES if the key is not readable by the caller.
+ EACCES if the key is not readable by the caller. In addition, the
+ function will return EMSGSIZE when the parameter kdf is non-NULL
+ and either the buffer length or the OtherInfo length exceeds the
+ allowed length.
===============
KERNEL SERVICES
diff --git a/include/linux/compat.h b/include/linux/compat.h
index f964ef7..00f348f 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -295,6 +295,13 @@ struct compat_old_sigaction {
};
#endif
+struct compat_keyctl_kdf_params {
+ compat_uptr_t kdfname;
+ compat_uptr_t otherinfo;
+ __u32 otherinfolen;
+ __u32 __spare[8];
+};
+
struct compat_statfs;
struct compat_statfs64;
struct compat_old_linux_dirent;
diff --git a/include/uapi/linux/keyctl.h b/include/uapi/linux/keyctl.h
index 86eddd6..0abe048 100644
--- a/include/uapi/linux/keyctl.h
+++ b/include/uapi/linux/keyctl.h
@@ -68,4 +68,11 @@ struct keyctl_dh_params {
__s32 base;
};
+struct keyctl_kdf_params {
+ char *kdfname;
+ char *otherinfo;
+ __u32 otherinfolen;
+ __u32 __spare[8];
+};
+
#endif /* _LINUX_KEYCTL_H */
diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index f826e87..56491fe 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -90,6 +90,7 @@ config KEY_DH_OPERATIONS
bool "Diffie-Hellman operations on retained keys"
depends on KEYS
select MPILIB
+ select CRYPTO_KDF
help
This option provides support for calculating Diffie-Hellman
public keys and shared secrets using values stored as keys
diff --git a/security/keys/Makefile b/security/keys/Makefile
index 1fd4a16..57dff0c 100644
--- a/security/keys/Makefile
+++ b/security/keys/Makefile
@@ -15,7 +15,8 @@ obj-y := \
request_key.o \
request_key_auth.o \
user_defined.o
-obj-$(CONFIG_KEYS_COMPAT) += compat.o
+compat-obj-$(CONFIG_KEY_DH_OPERATIONS) += compat_dh.o
+obj-$(CONFIG_KEYS_COMPAT) += compat.o $(compat-obj-y)
obj-$(CONFIG_PROC_FS) += proc.o
obj-$(CONFIG_SYSCTL) += sysctl.o
obj-$(CONFIG_PERSISTENT_KEYRINGS) += persistent.o
diff --git a/security/keys/compat.c b/security/keys/compat.c
index 36c80bf..b674886 100644
--- a/security/keys/compat.c
+++ b/security/keys/compat.c
@@ -133,8 +133,9 @@ COMPAT_SYSCALL_DEFINE5(keyctl, u32, option,
return keyctl_get_persistent(arg2, arg3);
case KEYCTL_DH_COMPUTE:
- return keyctl_dh_compute(compat_ptr(arg2), compat_ptr(arg3),
- arg4, compat_ptr(arg5));
+ return compat_keyctl_dh_compute(compat_ptr(arg2),
+ compat_ptr(arg3),
+ arg4, compat_ptr(arg5));
default:
return -EOPNOTSUPP;
diff --git a/security/keys/compat_dh.c b/security/keys/compat_dh.c
new file mode 100644
index 0000000..dc93e95e
--- /dev/null
+++ b/security/keys/compat_dh.c
@@ -0,0 +1,36 @@
+/* 32-bit compatibility syscall for 64-bit systems for DH operations
+ *
+ * Copyright (C) 2016 Stephan Mueller <smueller@chronox.de>
+ *
+ * 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 "internal.h"
+
+/*
+ * Perform the DH computation or DH based key derivation.
+ *
+ * If successful, 0 will be returned.
+ */
+long compat_keyctl_dh_compute(struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct compat_keyctl_kdf_params __user *kdf)
+{
+ struct keyctl_kdf_params kdfcopy;
+ struct compat_keyctl_kdf_params compat_kdfcopy;
+
+ if (!kdf)
+ return __keyctl_dh_compute(params, buffer, buflen, NULL);
+
+ if (copy_from_user(&compat_kdfcopy, kdf, sizeof(compat_kdfcopy)) != 0)
+ return -EFAULT;
+
+ kdfcopy.kdfname = compat_ptr(compat_kdfcopy.kdfname);
+ kdfcopy.otherinfo = compat_ptr(compat_kdfcopy.otherinfo);
+ kdfcopy.otherinfolen = compat_kdfcopy.otherinfolen;
+
+ return __keyctl_dh_compute(params, buffer, buflen, &kdfcopy);
+}
diff --git a/security/keys/dh.c b/security/keys/dh.c
index 531ed2e..8054454 100644
--- a/security/keys/dh.c
+++ b/security/keys/dh.c
@@ -77,9 +77,35 @@ error:
return ret;
}
-long keyctl_dh_compute(struct keyctl_dh_params __user *params,
- char __user *buffer, size_t buflen,
- void __user *reserved)
+static int keyctl_dh_compute_kdf(struct crypto_rng *tfm,
+ char __user *buffer, size_t buflen,
+ uint8_t *kbuf, size_t kbuflen)
+{
+ uint8_t *outbuf = NULL;
+ int ret;
+
+ outbuf = kmalloc(buflen, GFP_KERNEL);
+ if (!outbuf) {
+ ret = -ENOMEM;
+ goto err;
+ }
+
+ ret = crypto_rng_generate(tfm, kbuf, kbuflen, outbuf, buflen);
+ if (ret)
+ goto err;
+
+ ret = buflen;
+ if (copy_to_user(buffer, outbuf, buflen) != 0)
+ ret = -EFAULT;
+
+err:
+ kzfree(outbuf);
+ return ret;
+}
+
+long __keyctl_dh_compute(struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct keyctl_kdf_params *kdfcopy)
{
long ret;
MPI base, private, prime, result;
@@ -88,6 +114,7 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
uint8_t *kbuf;
ssize_t keylen;
size_t resultlen;
+ struct crypto_rng *tfm = NULL;
if (!params || (!buffer && buflen)) {
ret = -EINVAL;
@@ -98,12 +125,36 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
goto out;
}
- if (reserved) {
- ret = -EINVAL;
- goto out;
+ if (kdfcopy) {
+ char *kdfname;
+
+ if (buflen > KEYCTL_KDF_MAX_OUTPUT_LEN ||
+ kdfcopy->otherinfolen > KEYCTL_KDF_MAX_OI_LEN) {
+ ret = -EMSGSIZE;
+ goto out;
+ }
+
+ /* get KDF name string */
+ kdfname = strndup_user(kdfcopy->kdfname, CRYPTO_MAX_ALG_NAME);
+ if (IS_ERR(kdfname)) {
+ ret = PTR_ERR(kdfname);
+ goto out;
+ }
+
+ /* allocate KDF from the kernel crypto API */
+ tfm = crypto_alloc_rng(kdfname, 0, 0);
+ kfree(kdfname);
+ if (IS_ERR(tfm)) {
+ ret = PTR_ERR(tfm);
+ goto out;
+ }
}
- keylen = mpi_from_key(pcopy.prime, buflen, &prime);
+ /*
+ * If the caller requests postprocessing with a KDF, allow an
+ * arbitrary output buffer size since the KDF ensures proper truncation.
+ */
+ keylen = mpi_from_key(pcopy.prime, kdfcopy ? SIZE_MAX : buflen, &prime);
if (keylen < 0 || !prime) {
/* buflen == 0 may be used to query the required buffer size,
* which is the prime key length.
@@ -133,12 +184,25 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
goto error3;
}
- kbuf = kmalloc(resultlen, GFP_KERNEL);
+ /* allocate space for DH shared secret and SP800-56A otherinfo */
+ kbuf = kmalloc(kdfcopy ? (resultlen + kdfcopy->otherinfolen) : resultlen,
+ GFP_KERNEL);
if (!kbuf) {
ret = -ENOMEM;
goto error4;
}
+ /*
+ * Concatenate SP800-56A otherinfo past DH shared secret -- the
+ * input to the KDF is (DH shared secret || otherinfo)
+ */
+ if (kdfcopy && kdfcopy->otherinfo &&
+ copy_from_user(kbuf + resultlen, kdfcopy->otherinfo,
+ kdfcopy->otherinfolen) != 0) {
+ ret = -EFAULT;
+ goto error5;
+ }
+
ret = do_dh(result, base, private, prime);
if (ret)
goto error5;
@@ -147,12 +211,17 @@ long keyctl_dh_compute(struct keyctl_dh_params __user *params,
if (ret != 0)
goto error5;
- ret = nbytes;
- if (copy_to_user(buffer, kbuf, nbytes) != 0)
- ret = -EFAULT;
+ if (kdfcopy) {
+ ret = keyctl_dh_compute_kdf(tfm, buffer, buflen, kbuf,
+ resultlen + kdfcopy->otherinfolen);
+ } else {
+ ret = nbytes;
+ if (copy_to_user(buffer, kbuf, nbytes) != 0)
+ ret = -EFAULT;
+ }
error5:
- kfree(kbuf);
+ kzfree(kbuf);
error4:
mpi_free(result);
error3:
@@ -162,5 +231,22 @@ error2:
error1:
mpi_free(prime);
out:
+ if (tfm)
+ crypto_free_rng(tfm);
return ret;
}
+
+long keyctl_dh_compute(struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct keyctl_kdf_params __user *kdf)
+{
+ struct keyctl_kdf_params kdfcopy;
+
+ if (!kdf)
+ return __keyctl_dh_compute(params, buffer, buflen, NULL);
+
+ if (copy_from_user(&kdfcopy, kdf, sizeof(kdfcopy)) != 0)
+ return -EFAULT;
+
+ return __keyctl_dh_compute(params, buffer, buflen, &kdfcopy);
+}
diff --git a/security/keys/internal.h b/security/keys/internal.h
index a705a7d..cb5aec9 100644
--- a/security/keys/internal.h
+++ b/security/keys/internal.h
@@ -16,6 +16,8 @@
#include <linux/key-type.h>
#include <linux/task_work.h>
#include <linux/keyctl.h>
+#include <crypto/rng.h>
+#include <linux/compat.h>
struct iovec;
@@ -260,14 +262,29 @@ static inline long keyctl_get_persistent(uid_t uid, key_serial_t destring)
#ifdef CONFIG_KEY_DH_OPERATIONS
extern long keyctl_dh_compute(struct keyctl_dh_params __user *, char __user *,
- size_t, void __user *);
+ size_t, struct keyctl_kdf_params __user *);
+extern long __keyctl_dh_compute(struct keyctl_dh_params __user *, char __user *,
+ size_t, struct keyctl_kdf_params *);
+extern long compat_keyctl_dh_compute(struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct compat_keyctl_kdf_params __user *kdf);
+#define KEYCTL_KDF_MAX_OUTPUT_LEN 1024 /* max length of KDF output */
+#define KEYCTL_KDF_MAX_OI_LEN 64 /* max length of otherinfo */
#else
static inline long keyctl_dh_compute(struct keyctl_dh_params __user *params,
char __user *buffer, size_t buflen,
- void __user *reserved)
+ struct keyctl_kdf_params __user *kdf)
{
return -EOPNOTSUPP;
}
+
+static inline long compat_keyctl_dh_compute(
+ struct keyctl_dh_params __user *params,
+ char __user *buffer, size_t buflen,
+ struct keyctl_kdf_params __user *kdf)
+{
+ return -EOPNOTSUPP
+}
#endif
/*
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index d580ad0..b106898 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -1689,7 +1689,7 @@ SYSCALL_DEFINE5(keyctl, int, option, unsigned long, arg2, unsigned long, arg3,
case KEYCTL_DH_COMPUTE:
return keyctl_dh_compute((struct keyctl_dh_params __user *) arg2,
(char __user *) arg3, (size_t) arg4,
- (void __user *) arg5);
+ (struct keyctl_kdf_params __user *) arg5);
default:
return -EOPNOTSUPP;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Stephan Mueller @ 2016-08-10 6:25 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <866e31b50f364a87aabe94d2af03ecb8@aptaiexm02f.ap.qualcomm.com>
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not on the
> RNG entropy source. It is not surprising that the RNG input fails the
> entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each
> a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
> where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test, it
> will fail most of the tests, if not all. This does not mean this sequence
> is not appropriate as an entropy source, it just means we need twice more
> bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG
assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If
you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your
noise source to seed a DRNG from (i.e. have an entropy to data ratio of
significantly below 1). And the argument for the oversampling rate is always
a very interesting discussion. You apply 10/32. In private, I am wondering
about that ratio, but this should not be discussed here as I hope you have a
valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise
source before using it. Your current implementation simply does not allow
switching the noise source off to feed the input_pool with data that
increases the entropy estimator (at runtime).
Ciao
Stephan
^ permalink raw reply
* [PATCH v4] DH support: add KDF handling support
From: Stephan Mueller @ 2016-08-10 5:16 UTC (permalink / raw)
To: Mat Martineau; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1608091536470.24354@mjmartin-mac01.local>
Add the interface logic to support DH with KDF handling support.
The dh_compute code now allows the following options:
- no KDF support / output of raw DH shared secret:
dh_compute <private> <prime> <base>
- KDF support without "other information" string:
dh_compute_kdf <private> <prime> <base> <output length> <KDF type>
- KDF support with "other information string:
dh_compute_kdf_oi <private> <prime> <base> <output length> <KDF type>
where the OI string is provided on STDIN.
The test to verify the code is based on a test vector used for the CAVS
testing of SP800-56A.
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
Makefile | 1 +
keyctl.c | 133 ++++++++++++++++++++++++
keyutils.c | 14 +++
keyutils.h | 11 ++
man/keyctl_dh_compute.3 | 58 +++++++++++
tests/keyctl/dh_compute/valid/runtest.sh | 168 +++++++++++++++++++++++++++++++
tests/toolbox.inc.sh | 44 ++++++++
version.lds | 2 +
8 files changed, 431 insertions(+)
diff --git a/Makefile b/Makefile
index 824bbbf..90fc33f 100644
--- a/Makefile
+++ b/Makefile
@@ -195,6 +195,7 @@ endif
$(LNS) keyctl_read.3 $(DESTDIR)$(MAN3)/keyctl_read_alloc.3
$(LNS) recursive_key_scan.3 $(DESTDIR)$(MAN3)/recursive_session_key_scan.3
$(LNS) keyctl_dh_compute.3 $(DESTDIR)$(MAN3)/keyctl_dh_compute_alloc.3
+ $(LNS) keyctl_dh_compute.3 $(DESTDIR)$(MAN3)/keyctl_dh_compute_kdf.3
$(INSTALL) -D -m 0644 keyutils.h $(DESTDIR)$(INCLUDEDIR)/keyutils.h
###############################################################################
diff --git a/keyctl.c b/keyctl.c
index edb03de..fcf2f02 100644
--- a/keyctl.c
+++ b/keyctl.c
@@ -20,6 +20,7 @@
#include <errno.h>
#include <asm/unistd.h>
#include "keyutils.h"
+#include <limits.h>
struct command {
void (*action)(int argc, char *argv[]) __attribute__((noreturn));
@@ -67,6 +68,8 @@ static nr void act_keyctl_purge(int argc, char *argv[]);
static nr void act_keyctl_invalidate(int argc, char *argv[]);
static nr void act_keyctl_get_persistent(int argc, char *argv[]);
static nr void act_keyctl_dh_compute(int argc, char *argv[]);
+static nr void act_keyctl_dh_compute_kdf(int argc, char *argv[]);
+static nr void act_keyctl_dh_compute_kdf_oi(int argc, char *argv[]);
const struct command commands[] = {
{ act_keyctl___version, "--version", "" },
@@ -76,6 +79,8 @@ const struct command commands[] = {
{ act_keyctl_clear, "clear", "<keyring>" },
{ act_keyctl_describe, "describe", "<keyring>" },
{ act_keyctl_dh_compute, "dh_compute", "<private> <prime> <base>" },
+ { act_keyctl_dh_compute_kdf, "dh_compute_kdf", "<private> <prime> <base> <len> <kdf>" },
+ { act_keyctl_dh_compute_kdf_oi, "dh_compute_kdf_oi", "<private> <prime> <base> <len> <kdf>" },
{ act_keyctl_instantiate, "instantiate","<key> <data> <keyring>" },
{ act_keyctl_invalidate,"invalidate", "<key>" },
{ act_keyctl_get_persistent, "get_persistent", "<keyring> [<uid>]" },
@@ -1663,6 +1668,7 @@ static void act_keyctl_dh_compute(int argc, char *argv[])
}
printf("%02hhx", *p);
+ *p = 0x00; /* zeroize buffer */
p++;
col++;
@@ -1674,6 +1680,133 @@ static void act_keyctl_dh_compute(int argc, char *argv[])
} while (--ret > 0);
printf("\n");
+
+ free(buffer);
+
+ exit(0);
+}
+
+static void act_keyctl_dh_compute_kdf(int argc, char *argv[])
+{
+ key_serial_t private, prime, base;
+ char *buffer;
+ char *p;
+ int ret, sep, col;
+ unsigned long buflen = 0;
+
+ if (argc != 6)
+ format();
+
+ private = get_key_id(argv[1]);
+ prime = get_key_id(argv[2]);
+ base = get_key_id(argv[3]);
+
+ buflen = strtoul(argv[4], NULL, 10);
+ if (buflen == ULONG_MAX)
+ error("dh_compute: cannot convert generated length value");
+
+ buffer = malloc(buflen);
+ if (!buffer)
+ error("dh_compute: cannot allocate memory");
+
+ ret = keyctl_dh_compute_kdf(private, prime, base, argv[5], NULL, 0,
+ buffer, buflen);
+ if (ret < 0)
+ error("keyctl_dh_compute_alloc");
+
+ /* hexdump the contents */
+ printf("%u bytes of data in result:\n", ret);
+
+ sep = 0;
+ col = 0;
+ p = buffer;
+
+ do {
+ if (sep) {
+ putchar(sep);
+ sep = 0;
+ }
+
+ printf("%02hhx", *p);
+ *p = 0x00; /* zeroize buffer */
+ p++;
+
+ col++;
+ if (col % 32 == 0)
+ sep = '\n';
+ else if (col % 4 == 0)
+ sep = ' ';
+
+ } while (--ret > 0);
+
+ printf("\n");
+
+ free(buffer);
+
+ exit(0);
+}
+
+static void act_keyctl_dh_compute_kdf_oi(int argc, char *argv[])
+{
+ key_serial_t private, prime, base;
+ char *buffer;
+ char *p;
+ int ret, sep, col;
+ unsigned long buflen = 0;
+ size_t oilen;
+ void *oi;
+
+ if (argc != 6)
+ format();
+
+ private = get_key_id(argv[1]);
+ prime = get_key_id(argv[2]);
+ base = get_key_id(argv[3]);
+
+ buflen = strtoul(argv[4], NULL, 10);
+ if (buflen == ULONG_MAX)
+ error("dh_compute: cannot convert generated length value");
+
+ buffer = malloc(buflen);
+ if (!buffer)
+ error("dh_compute: cannot allocate memory");
+
+ oi = grab_stdin(&oilen);
+
+ ret = keyctl_dh_compute_kdf(private, prime, base, argv[5], oi, oilen,
+ buffer, buflen);
+ if (ret < 0)
+ error("keyctl_dh_compute_alloc");
+
+ /* hexdump the contents */
+ printf("%u bytes of data in result:\n", ret);
+
+ sep = 0;
+ col = 0;
+ p = buffer;
+
+ do {
+ if (sep) {
+ putchar(sep);
+ sep = 0;
+ }
+
+ printf("%02hhx", *p);
+ *p = 0x00; /* zeroize buffer */
+ p++;
+
+ col++;
+ if (col % 32 == 0)
+ sep = '\n';
+ else if (col % 4 == 0)
+ sep = ' ';
+
+ } while (--ret > 0);
+
+ printf("\n");
+
+ free(buffer);
+
exit(0);
}
diff --git a/keyutils.c b/keyutils.c
index 2a69304..2c3c4e6 100644
--- a/keyutils.c
+++ b/keyutils.c
@@ -244,6 +244,20 @@ long keyctl_dh_compute(key_serial_t private, key_serial_t prime,
return keyctl(KEYCTL_DH_COMPUTE, ¶ms, buffer, buflen, 0);
}
+long keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
+ key_serial_t base, char *kdfname, char *otherinfo,
+ size_t otherinfolen, char *buffer, size_t buflen)
+{
+ struct keyctl_dh_params params = { .private = private,
+ .prime = prime,
+ .base = base };
+ struct keyctl_kdf_params kdfparams = { .kdfname = kdfname,
+ .otherinfo = otherinfo,
+ .otherinfolen = otherinfolen };
+
+ return keyctl(KEYCTL_DH_COMPUTE, ¶ms, buffer, buflen, &kdfparams);
+}
+
/*****************************************************************************/
/*
* fetch key description into an allocated buffer
diff --git a/keyutils.h b/keyutils.h
index b321aa8..65df9fd 100644
--- a/keyutils.h
+++ b/keyutils.h
@@ -108,6 +108,13 @@ struct keyctl_dh_params {
key_serial_t base;
};
+struct keyctl_kdf_params {
+ char *kdfname;
+ char *otherinfo;
+ uint32_t otherinfolen;
+ uint32_t __spare[8];
+};
+
/*
* syscall wrappers
*/
@@ -163,6 +170,10 @@ extern long keyctl_invalidate(key_serial_t id);
extern long keyctl_get_persistent(uid_t uid, key_serial_t id);
extern long keyctl_dh_compute(key_serial_t private, key_serial_t prime,
key_serial_t base, char *buffer, size_t buflen);
+extern long keyctl_dh_compute_kdf(key_serial_t private, key_serial_t prime,
+ key_serial_t base, char *kdfname,
+ char *otherinfo, size_t otherinfolen,
+ char *buffer, size_t buflen);
/*
* utilities
diff --git a/man/keyctl_dh_compute.3 b/man/keyctl_dh_compute.3
index b06d39e..f630dc3 100644
--- a/man/keyctl_dh_compute.3
+++ b/man/keyctl_dh_compute.3
@@ -11,6 +11,8 @@
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH NAME
keyctl_dh_compute \- Compute a Diffie-Hellman shared secret or public key
+.br
+keyctl_dh_compute_kdf \- Derive key from a Diffie-Hellman shared secret
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH SYNOPSIS
.nf
@@ -21,6 +23,10 @@ keyctl_dh_compute \- Compute a Diffie-Hellman shared secret or public key
.sp
.BI "long keyctl_dh_compute_alloc(key_serial_t " private,
.BI "key_serial_t " prime ", key_serial_t " base ", void **" _buffer ");"
+.sp
+.BI "long keyctl_dh_compute_kdf(key_serial_t " private ", key_serial_t " prime ,
+.BI "key_serial_t " base ", char *" kdfname ", char *" otherinfo ",
+.BI "size_t " otherinfolen ", char *" buffer ", size_t " buflen ");"
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH DESCRIPTION
.BR keyctl_dh_compute ()
@@ -64,6 +70,49 @@ places the data in it. If successful, a pointer to the buffer is placed in
.IR *_buffer .
The caller must free the buffer.
.P
+.BR keyctl_dh_compute_kdf ()
+derives a key from a Diffie-Hellman shared secret according to the protocol
+specified in SP800-56A. The Diffie-Hellman computation is based on the same
+primitives as discussed
+for
+.BR keyctl_dh_compute ().
+.P
+To implement the protocol of SP800-56A
+.I base
+is a key containing the remote public key to compute the Diffie-Hellman
+shared secret. That shared secret is post-processed with a key derivation
+function.
+.P
+The
+.I kdfname
+specifies the Linux kernel crypto API name for a key derivation function
+using a non-keyed hash, such as kdf_ctr(sha256). Using the counter KDF function
+specified with kdf_ctr() makes the key derivation compliant to SP800-56A.
+The
+.I kdfname
+must be a NULL terminated string.
+.P
+Following the specification of SP800-56A section 5.8.1.2 the
+.I otherinfo
+parameter may be provided. The format of the OtherInfo field is defined
+by the caller. The caller may also specify NULL as a valid argument when
+no OtherInfo data shall be processed. The length of the
+.I otherinfo
+parameter is specified with
+.I otherinfolen
+and is restricted to a maximum length by the kernel.
+.P
+The KDF returns the requested number of bytes specified with the
+.I genlen
+or the
+.I buflen
+parameter depending on the invoked function.
+.P
+.I buffer
+and
+.I buflen
+specify the buffer into which the computed result will be placed.
+.P
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH RETURN VALUE
On success
@@ -91,6 +140,15 @@ The buffer pointer is invalid or buflen is too small.
.TP
.B EOPNOTSUPP
One of the keys was not a valid user key.
+.TP
+.B EMSGSIZE
+When using
+.BR keyctl_dh_compute_kdf (),
+the size of either
+.I otherinfolen
+or
+.I buflen
+is too big.
.\"""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
.SH LINKING
This is a library function that can be found in
diff --git a/tests/keyctl/dh_compute/valid/runtest.sh b/tests/keyctl/dh_compute/valid/runtest.sh
index f2aace6..d8e338b 100644
--- a/tests/keyctl/dh_compute/valid/runtest.sh
+++ b/tests/keyctl/dh_compute/valid/runtest.sh
@@ -84,5 +84,173 @@ expect_multiline payload "$public"
echo "++++ FINISHED TEST: $result" >>$OUTPUTFILE
+
+################################################################
+# Testing DH compute with KDF according to SP800-56A
+#
+# test vectors from http://csrc.nist.gov/groups/STM/cavp/documents/keymgmt/KASTestVectorsFFC2014.zip
+################################################################
+
+# SHA-256
+
+# XephemCAVS
+private="\x81\xb2\xc6\x5f\x5c\xba\xc0\x0b\x13\x53\xac\x38\xbd\x77\xa2\x5a"
+private+="\x86\x50\xed\x48\x5e\x41\x3e\xac\x1d\x6c\x48\x85"
+
+# P
+prime="\xa3\xcc\x62\x23\xe5\x0c\x6e\x3f\x7b\xb0\x58\x1d\xcb\x9e\x9f\xf0"
+prime+="\x2c\x58\x07\x68\x32\x8a\x15\x20\x7b\x1c\x32\x31\x7f\xb7\x84\x96"
+prime+="\x81\x5e\x3c\xf7\xf9\xd0\x9c\xcb\x9f\xa8\x40\xff\x47\x98\x51\x1a"
+prime+="\x17\xb5\x59\x28\x72\x1e\x5d\xfb\xcc\xc5\x41\x47\xe0\xf0\x5f\x85"
+prime+="\xb3\xac\x41\x0b\x6a\xe3\xf5\x9b\x79\x6f\x3f\xea\xc7\xfc\x52\x49"
+prime+="\x21\x7e\xb2\xa0\x45\x88\x29\x3a\x5a\xde\x22\x78\x79\xf4\x6c\xeb"
+prime+="\x56\x45\x7b\x5c\x43\x12\x93\xe5\xe1\x04\xd1\xb9\x64\xbd\x2c\xdf"
+prime+="\xde\xff\xa0\x40\x49\xa9\x1e\x67\xee\x8c\x86\xe9\x44\xf0\x4f\x94"
+prime+="\x4a\x30\xe3\x61\xf8\xd1\x5d\x17\xe5\x01\x0c\xab\xb4\xef\x40\xc0"
+prime+="\xeb\xa5\xf4\xa2\x52\xd4\xfd\x6c\xf9\xda\xe6\x0e\x86\xe4\xb3\x00"
+prime+="\x9b\x1d\xfc\x92\x66\x70\x35\x72\x61\x58\x7a\xd0\x5c\x00\xa6\xc6"
+prime+="\xf0\x10\x6c\xec\x8f\xc5\x91\x31\x51\x50\x84\xa8\x70\x59\x41\x65"
+prime+="\xb4\x93\x90\xdb\x2d\x00\xe7\x53\x8f\x23\x0d\x53\x2f\x4a\x4e\xca"
+prime+="\x83\x09\xd7\x07\xc0\xb3\x83\x5c\xee\x04\xf3\xca\x55\x8a\x22\xc6"
+prime+="\xb5\x20\xfe\x25\xde\x6f\xfa\x90\xef\xda\x49\x27\xd0\x18\x59\x4c"
+prime+="\x0c\x0b\x77\x06\x73\x93\xb7\xf1\xe0\xfc\x7c\xf2\x16\xaf\xf3\x9f"
+
+# YephemIUT
+xa="\x9a\x70\x82\x2d\x3f\x06\x12\x3d\x0e\x51\x8e\xe1\x16\x51\xe5\xf6"
+xa+="\xb1\x19\xdc\x3b\x97\xd5\xb1\xc0\xa2\xa6\xf6\xde\x94\x25\x64\xba"
+xa+="\x10\x06\x1e\xec\xde\xb7\x36\x9c\xa5\x37\x49\x9e\x04\xb0\x36\xe9"
+xa+="\x7f\x44\x5a\x95\x6f\x63\x69\xae\x6e\x63\xfd\x27\xea\xe3\xe3\x47"
+xa+="\x85\x54\x47\xd3\xba\xc1\xc6\x0c\x10\xe7\x35\x07\x72\xc6\xc0\xc6"
+xa+="\xfb\xf9\xca\x3e\x38\xf0\xe8\x65\x88\x25\xd3\xb2\x0f\x1f\x02\x8f"
+xa+="\x35\xe3\x4d\x12\x35\x10\x3d\xf2\x33\x9b\x5b\x09\x9d\x3f\xe3\xe5"
+xa+="\x34\x6a\x69\x16\x42\xba\xc5\xb0\xbb\x03\xcd\x5d\x04\xd7\x56\x26"
+xa+="\x21\x49\x3f\xf1\xc4\x27\x3b\x6a\x45\xc5\xec\xb0\xb5\xe9\x08\xa0"
+xa+="\xf9\xf5\x62\x28\x2e\x85\x3e\xfc\x9a\x7e\xa1\x12\xe9\x47\x4f\xf6"
+xa+="\x94\x18\xf7\xc4\x7a\xe9\x66\xd4\x52\x4c\xa1\x70\x1b\x60\xa4\xbe"
+xa+="\x15\xc7\x5e\x27\xb4\x05\x80\x64\x68\x15\x6e\x02\xcb\xc5\x8f\xf4"
+xa+="\x66\x3c\x96\xac\x0c\x87\x36\x81\x35\xfa\x9b\x0b\xb6\x33\x7a\xe2"
+xa+="\x58\x52\x1d\x7d\x60\xc2\xa9\x1b\x4e\xd7\x72\xad\x65\x03\x40\x49"
+xa+="\x97\xf6\x79\x9d\xf6\x63\xa8\x99\x9c\xfd\x74\x7f\xa0\x67\xb9\x05"
+xa+="\x8a\xb3\x3b\xc1\x45\x94\x36\x6f\x28\xf5\xa2\xd9\x00\xb6\x46\x7a"
+
+# Z
+read -d '' shared <<"EOF"
+0fdbd9a2 ebf50cba 489b4e4d 7cd6924a 42ee6324 a26988b2 22bc38e6 9cc445f1
+eb47c1a4 62eca39f 39bcd7b8 19dede51 30bc38da ec99c16f 40a4e5c1 9c97b796
+8b41823d a0650e37 13c73e6f 5f2a9dff 2e67dbf5 40ee66f4 e694c28f ba1d604b
+71b57b8a eeb67a35 ba425a38 490b6fb9 f713db22 6f893b7a 8962f426 ba3046fb
+cff8538c 16f583e8 ae947672 0ba55ff9 75b440d0 c4565cc7 5837d23a fea61a39
+e0b7f6c4 e24c2154 7eb19fce f8dbed10 b06a9cce 971c0f0f ba7c1d5c b5035eaa
+4fddd3ba fe757339 e3321e3e 4ebfe9e7 9c6c0401 4df63cf9 28d0a2c0 5b2d5521
+030c35f1 c84c97fe 64cad509 8012a003 d52d24c4 1a1f9348 b7575251 3facb02f
+EOF
+
+# OI
+otherinfo="\xa1\xb2\xc3\xd4\xe5\x43\x41\x56\x53\x69\x64\x0d\x64\xc1\xb2"
+otherinfo+="\x33\x61\xb2\x61\xde\x78\x68\x8e\xa8\x65\xfc\xff\x11\x3c\x84"
+
+# DKM
+read -d '' derived <<"EOF"
+8284e313 02c8a26b 393ec52d 9f9e0882
+EOF
+
+pcreate_key "-e $prime" user dh:prime @s
+expect_keyid primeid
+
+pcreate_key "-e $xa" user dh:xa @s
+expect_keyid xaid
+
+pcreate_key "-e $private" user dh:private @s
+expect_keyid privateid
+
+marker "COMPUTE DH SHARED SECRET"
+dh_compute $privateid $primeid $xaid
+expect_multiline payload "$shared"
+
+marker "COMPUTE DERIVED KEY FROM DH SHARED SECRET (SHA-256)"
+echo -e -n $otherinfo | dh_compute_kdf_oi $privateid $primeid $xaid 16 "kdf_ctr(sha256)"
+expect_multiline payload "$derived"
+
+
+# SHA-224
+
+# XephemCAVS
+private="\x86\x1b\xa2\x59\xab\xa6\xaa\x57\x7d\xe2\x2f\x50\x8e\xcb\xbc\x26"
+private+="\xc5\xac\xfc\xcb\x9e\xa2\x3b\x43\x4d\x6d\x2b\x79"
+
+# P
+prime="\xa5\xb1\x76\x4e\x13\xc8\x16\x99\xab\xa3\x8f\x0d\xc0\xd1\x5e\x15"
+prime+="\xf5\x0f\xcd\x5c\xf7\xc2\x23\x72\xca\xfc\x5e\xd7\x62\x94\x1b\xd9"
+prime+="\xe0\xfb\x9a\xab\xee\x74\x66\xd2\xc8\x29\xaa\xb0\x31\xdb\x7b\x1b"
+prime+="\x5a\x64\xe6\x8e\xd5\x3b\xaf\xb2\x83\xba\x0f\x01\x8b\xeb\x3e\xdc"
+prime+="\x95\x7f\xe4\x53\xbe\x0d\xaa\xb6\x1b\x32\x28\x76\x3e\x80\x75\x8c"
+prime+="\x6d\x8c\x28\x3c\xf6\x30\xed\xd9\xd7\x0a\x8a\xf3\x30\xdd\x0a\xf6"
+prime+="\xa8\xd5\x94\xc2\x3c\xdd\x24\xc8\xad\x3f\xcf\xea\x41\x75\x77\x72"
+prime+="\xce\xed\x92\x1e\x63\x86\x2f\x24\x6e\x6f\x49\xd8\x74\x7e\x44\xae"
+prime+="\xf0\x1e\x30\x9b\x6d\xcc\x80\xd4\x50\x38\x3b\xb1\xf9\x4d\xd5\x90"
+prime+="\x84\xf8\xe9\x6f\x85\x6e\xc7\xc8\x33\x5e\xdb\x05\x5f\x8e\xc6\xc4"
+prime+="\x81\x52\x0b\x3f\x28\xe8\x0b\x62\x09\xb8\xae\x61\xcc\x86\x0e\x24"
+prime+="\xc8\x22\xb6\x6c\x4f\x97\x80\x49\x93\xbc\xd0\xa9\x72\xb3\x53\x54"
+prime+="\x01\x33\x0e\xbe\x4b\x2e\x92\x3f\x18\x9b\x63\x35\x62\xe4\x68\xeb"
+prime+="\x99\xa4\xbc\x88\xcc\xbf\xf8\xdf\x0f\xd5\xaf\xcf\xe6\xae\x19\x18"
+prime+="\x42\x14\xab\x3f\xef\xb7\xf0\x66\x8b\x8b\x26\x83\xbe\xbd\x56\x51"
+prime+="\xa4\xc6\x38\x43\xb9\xb1\x4b\xc7\x38\xd5\x20\xb1\xb7\x21\x2c\x69"
+
+# YephemIUT
+xa="\x17\xd7\x1a\xf4\x35\x3c\x22\x12\x2a\xeb\x2a\x06\x19\xcc\x2c\xf7"
+xa+="\x35\x53\xf2\x8e\x9f\xb1\x91\xfd\xb2\x86\xb1\x15\xb9\xfd\xa8\x66"
+xa+="\x2d\xe5\x17\x3b\x1a\xff\x70\x48\x8d\x9b\xc8\x48\xe5\x37\xd7\xe5"
+xa+="\x02\x16\x49\xd3\x7d\xc7\x8c\x94\x36\x9d\xb9\x0c\x27\x84\xc9\x4d"
+xa+="\x97\x0a\xc9\xb5\xe3\x5e\xfd\x22\xd4\x18\xd3\x1b\x68\xd9\x55\x0b"
+xa+="\xaa\x77\x16\xe9\x8e\xa6\x78\x3b\xb3\xa8\x45\x05\x9f\xba\xa4\xa6"
+xa+="\x72\x0a\x6a\x23\xc5\x6b\xa5\x2b\x4d\x9b\x72\x6e\x00\x68\xe9\xeb"
+xa+="\x4d\x17\x5b\xff\x43\x69\xf3\xd2\xa4\xaf\x66\xee\xcd\x62\xef\x7b"
+xa+="\x23\xc3\x37\xd4\x70\x95\x2b\x17\x67\xc8\xbf\x78\x2f\x0b\x58\xb4"
+xa+="\xfc\x82\x45\xf8\x40\x78\x71\x70\xf4\xb0\xa5\x1b\x5e\xb4\x60\x75"
+xa+="\x8a\xdd\xc9\xf4\x4a\x73\xa3\xf6\x07\x60\x3b\xd3\x50\x73\xd1\xa6"
+xa+="\x9a\x20\x3a\x04\x94\xa8\xc2\x02\x1b\xa0\xda\x1f\x04\x95\xf5\x60"
+xa+="\xc0\xba\x81\x79\x4e\xee\xeb\x82\x5d\x1b\xd3\x43\x16\xa5\x2a\xe1"
+xa+="\xc9\x00\x10\x0c\x0d\x6f\xa0\x25\x46\xed\x7a\x9c\x38\xa6\xa3\x43"
+xa+="\xd6\x86\x59\xee\xb5\x9c\xf3\x81\x04\xa9\x6b\xb2\x5a\x6d\xbb\xf0"
+xa+="\xcb\xc0\xed\xe7\x3a\x7b\xba\x67\x51\x81\xe0\xcd\x2e\x7b\x9f\x89"
+
+# Z
+read -d '' shared <<"EOF"
+057c22b8 c5872fef 08ebe852 fafab4b7 c2c2ffbb 376d71bd a941b16e 32614adf
+ebb82aeb d50f29d3 cec63d10 77f50e21 cf381b87 a818c614 52c5cce2 af85f40c
+06615b97 fe8c3a80 68990ac5 83957b52 8dd6d52d a3b51e84 aec355fd 4a3fe5ce
+faa3b17c 9e71cb4d 28ecab6d 21297280 e52397b7 ccb1b62d 8d5d3ce4 1d26b2a3
+bdbf880b b39e8b02 8a745ff2 9f0984da efe97084 5d850884 525403ca d2a52956
+f55b9a89 b2d801f1 710333c0 479c5955 b54c8163 83c65ad9 c78b8c67 cc1b211b
+208b9fab b9c99a68 18293e6a 8da069e6 75eb4317 668a7d4b 6f235533 f3ff4ed0
+4f8ad579 f9ad14e7 f68ae183 41d603d9 d6297123 00716c98 bbbf16eb 2a2cc92f
+EOF
+
+# OI
+otherinfo="\xa1\xb2\xc3\xd4\xe5\x43\x41\x56\x53\x69\x64\xaa\x27\xe2\x49"
+otherinfo+="\xbf\x0a\x12\x76\x46\x8d\x80\x82\x59\xf3\xb8\xe2\x68\x78\x51"
+
+# DKM
+read -d '' derived <<"EOF"
+88bf39c0 08eec33a dc3b4430 054ba262
+EOF
+
+pcreate_key "-e $prime" user dh:prime @s
+expect_keyid primeid
+
+pcreate_key "-e $xa" user dh:xa @s
+expect_keyid xaid
+
+pcreate_key "-e $private" user dh:private @s
+expect_keyid privateid
+
+marker "COMPUTE DH SHARED SECRET"
+dh_compute $privateid $primeid $xaid
+expect_multiline payload "$shared"
+
+marker "COMPUTE DERIVED KEY FROM DH SHARED SECRET (SHA-224)"
+echo -e -n $otherinfo | dh_compute_kdf_oi $privateid $primeid $xaid 16 "kdf_ctr(sha224)"
+expect_multiline payload "$derived"
+
# --- then report the results in the database ---
toolbox_report_result $TEST $result
diff --git a/tests/toolbox.inc.sh b/tests/toolbox.inc.sh
index 7f19a02..27b253f 100644
--- a/tests/toolbox.inc.sh
+++ b/tests/toolbox.inc.sh
@@ -1106,6 +1106,50 @@ function dh_compute ()
###############################################################################
#
+# Do a DH computation post-processed by a KDF
+#
+###############################################################################
+function dh_compute_kdf ()
+{
+ my_exitval=0
+ if [ "x$1" = "x--fail" ]
+ then
+ my_exitval=1
+ shift
+ fi
+
+ echo keyctl dh_compute_kdf $@ >>$OUTPUTFILE
+ keyctl dh_compute_kdf $@ >>$OUTPUTFILE 2>&1
+ if [ $? != $my_exitval ]
+ then
+ failed
+ fi
+}
+
+###############################################################################
+#
+# Do a DH computation post-processed by a KDF with other information
+#
+###############################################################################
+function dh_compute_kdf_oi ()
+{
+ my_exitval=0
+ if [ "x$1" = "x--fail" ]
+ then
+ my_exitval=1
+ shift
+ fi
+
+ echo keyctl dh_compute_kdf_oi $@ >>$OUTPUTFILE
+ keyctl dh_compute_kdf_oi $@ >>$OUTPUTFILE 2>&1
+ if [ $? != $my_exitval ]
+ then
+ failed
+ fi
+}
+
+###############################################################################
+#
# Make sure we sleep at least N seconds
#
###############################################################################
diff --git a/version.lds b/version.lds
index 2bfed13..b8eebfb 100644
--- a/version.lds
+++ b/version.lds
@@ -66,5 +66,7 @@ KEYUTILS_1.6 {
/* management functions */
keyctl_dh_compute;
keyctl_dh_compute_alloc;
+ keyctl_dh_compute_kdf;
+ keyctl_dh_compute_kdf_alloc;
} KEYUTILS_1.5;
--
2.7.4
^ permalink raw reply related
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:15 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, jason@lakedaemon.net,
Sepehrdad, Pouyan
In-Reply-To: <1526134.1iUazSISyZ@positron.chronox.de>
Hi Stephan,
NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the amount of min entropy the source provides, and not to decide if the source has passed the tests or failed. See
https://github.com/usnistgov/SP800-90B_EntropyAssessment
The goal is often to make sure the input entropy is more than the entropy we expect from the output.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 2:52 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH
From: Stephan Mueller @ 2016-08-10 5:06 UTC (permalink / raw)
To: Mat Martineau; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <alpine.OSX.2.20.1608091546100.24354@mjmartin-mac01.local>
Am Dienstag, 9. August 2016, 15:48:00 CEST schrieb Mat Martineau:
Hi Mat,
> On Sat, 6 Aug 2016, Stephan Mueller wrote:
> > diff --git a/security/keys/internal.h b/security/keys/internal.h
> > index a705a7d..7659b52 100644
> > --- a/security/keys/internal.h
> > +++ b/security/keys/internal.h
> > @@ -259,15 +259,32 @@ static inline long keyctl_get_persistent(uid_t uid,
> > key_serial_t destring) #endif
> >
> > #ifdef CONFIG_KEY_DH_OPERATIONS
> > +#include <crypto/rng.h>
> > +#include <linux/compat.h>
>
> These may belong at the top of the file, even if they are only used when
> CONFIG_KEY_DH_OPERATIONS is defined.
Sure. As I have seen also this coding style in the kernel, I thought it would
make sense here too. But I will move it.
>
> > extern long keyctl_dh_compute(struct keyctl_dh_params __user *, char
> > __user *, - size_t, void __user *);
> > + size_t, struct keyctl_kdf_params __user *);
> > +extern long __keyctl_dh_compute(struct keyctl_dh_params __user *, char
> > __user *, + size_t, struct keyctl_kdf_params *);
> > +extern long compat_keyctl_dh_compute(struct keyctl_dh_params __user
> > *params, + char __user *buffer, size_t buflen,
> > + struct compat_keyctl_kdf_params __user *kdf);
> > +#define KEYCTL_KDF_MAX_OUTPUT_LEN 1024 /* max length of KDF output */
> > +#define KEYCTL_KDF_MAX_OI_LEN 64 /* max length of otherinfo */
> > #else
> > static inline long keyctl_dh_compute(struct keyctl_dh_params __user
> > *params,>
> > char __user *buffer, size_t buflen,
> >
> > - void __user *reserved)
> > + struct keyctl_kdf_params __user *kdf)
> > {
> >
> > return -EOPNOTSUPP;
> >
> > }
> > +
> > +static inline long compat_keyctl_dh_compute(
> > + struct keyctl_dh_params __user *params,
> > + char __user *buffer, size_t buflen,
> > + struct keyctl_kdf_params __user *kdf)
> > +{
> > + return -EOPNOTSUPP
> > +}
> > #endif
> >
> > /*
> > diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
> > index d580ad0..b106898 100644
> > --- a/security/keys/keyctl.c
> > +++ b/security/keys/keyctl.c
> > @@ -1689,7 +1689,7 @@ SYSCALL_DEFINE5(keyctl, int, option, unsigned long,
> > arg2, unsigned long, arg3,>
> > case KEYCTL_DH_COMPUTE:
> > return keyctl_dh_compute((struct keyctl_dh_params __user *) arg2,
> >
> > (char __user *) arg3, (size_t) arg4,
> >
> > - (void __user *) arg5);
> > + (struct keyctl_kdf_params __user *) arg5);
> >
> > default:
> > return -EOPNOTSUPP;
>
> Regards,
> --
> Mat Martineau
> Intel OTC
Ciao
Stephan
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-10 13:24 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Stephan Mueller, Herbert Xu, Matt Mackall,
miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Valo, Kalle,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath9k-devel, linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Sepehrdad, Pouyan
In-Reply-To: <389c3c1fdde2447aacf31a8b4aadfc08-fhY3XlRGNI1pWAYlkNb9jaRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
Hi Miaoqing Pan, Stephen,
*gentle reminder: others are reading which may not be directly included
in the conversation. Including the archives. Please avoid top posting.
:)
On Wed, Aug 10, 2016 at 07:43:45AM +0000, Pan, Miaoqing wrote:
> The problem with using the add_device_randomness is that we do not
> know when to call that API, and we have to make our solution either
> timer-based or interrupt based, which is not really the correct way of
> implementing this feature.
Exactly. I think we're dancing around the problem by discussing the
quality of what the ath9k adc provides.
The fact is, barring userspace expectations of /dev/hwrng, hw_random is
the appropriate place for it. It's not a devicetree blob, mac address,
or pci config space. Which are things we feed in once for the heck of
it. This is a *continuous* source or questionable quality.
I'm seriously considering putting this and timeriomem-rng into a
subdirectory under hw_random/, maybe environ/. Anything in there gets
quality=0 for default, and *doesn't* contribute to /dev/hwrng.
Regardless which path we take, I think we should include 'adc' in the
name. I've heard countless times about "Atheros cards come with an rng
on board". :-/
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* [PATCH 5/6] crypto: sun4i-ss: Always use sun4i_tfm_ctx for storing pointer to dev ss
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
The dev *ss is stored both in sun4i_tfm_ctx and sun4i_req_ctx.
Since this pointer will never be changed during tfm life, it is better
to remove it from sun4i_req_ctx.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 13 +++++++++++--
drivers/crypto/sunxi-ss/sun4i-ss.h | 1 -
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 60031e0..2ee3b59 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -20,6 +20,15 @@
int sun4i_hash_crainit(struct crypto_tfm *tfm)
{
+ struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
+ struct ahash_alg *alg = __crypto_ahash_alg(tfm->__crt_alg);
+ struct sun4i_ss_alg_template *algt;
+
+ memset(op, 0, sizeof(struct sun4i_tfm_ctx));
+
+ algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
+ op->ss = algt->ss;
+
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct sun4i_req_ctx));
return 0;
@@ -36,7 +45,6 @@ int sun4i_hash_init(struct ahash_request *areq)
memset(op, 0, sizeof(struct sun4i_req_ctx));
algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
- op->ss = algt->ss;
op->mode = algt->mode;
return 0;
@@ -168,8 +176,9 @@ int sun4i_hash(struct ahash_request *areq)
*/
struct sun4i_req_ctx *op = ahash_request_ctx(areq);
- struct sun4i_ss_ctx *ss = op->ss;
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
+ struct sun4i_tfm_ctx *tfmctx = crypto_ahash_ctx(tfm);
+ struct sun4i_ss_ctx *ss = tfmctx->ss;
unsigned int in_i = 0; /* advancement in the current SG */
unsigned int end;
/*
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
index ece5a1c..f04c0f8 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -163,7 +163,6 @@ struct sun4i_req_ctx {
u32 hash[5]; /* for storing SS_IVx register */
char buf[64];
unsigned int len;
- struct sun4i_ss_ctx *ss;
int flags;
};
--
2.7.3
^ permalink raw reply related
* [PATCH 4/6] crypto: sun4i-ss: fix spelling
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
Two words are badly spelled, this patch respell them.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 7841d73..60031e0 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -372,7 +372,7 @@ int sun4i_hash(struct ahash_request *areq)
* I do not check RX FIFO size in this function since the size is 32
* after each enabling and this function neither write more than 32 words.
* If we come from the update part, we cannot have more than
- * 3 remainings bytes to write and SS is fast enought to not care about it.
+ * 3 remaining bytes to write and SS is fast enough to not care about it.
*/
hash_final:
@@ -436,7 +436,7 @@ hash_final:
/*
* Wait for SS to finish the hash.
- * The timeout could happen only in case of bad overcloking
+ * The timeout could happen only in case of bad overclocking
* or driver bug.
*/
i = 0;
--
2.7.3
^ permalink raw reply related
* [PATCH 2/6] crypto: sun4i-ss: unify update/final function
From: LABBE Corentin @ 2016-08-10 9:45 UTC (permalink / raw)
To: herbert, davem, maxime.ripard, wens
Cc: linux-crypto, linux-kernel, LABBE Corentin
In-Reply-To: <1470822334-20672-1-git-send-email-clabbe.montjoie@gmail.com>
The update and final functions have lots of common action.
This patch mix them in one function.
This will give some improvements:
- This will permit asynchronous support more easily
- This will permit to use finup/digest functions with some performance
improvements
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 147 ++++++++++++++++++--------------
drivers/crypto/sunxi-ss/sun4i-ss.h | 1 +
2 files changed, 85 insertions(+), 63 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index ff80314..2fb0684 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -129,6 +129,9 @@ int sun4i_hash_import_sha1(struct ahash_request *areq, const void *in)
return 0;
}
+#define SS_HASH_UPDATE 1
+#define SS_HASH_FINAL 2
+
/*
* sun4i_hash_update: update hash engine
*
@@ -156,7 +159,7 @@ int sun4i_hash_import_sha1(struct ahash_request *areq, const void *in)
* write remaining data in op->buf
* final state op->len=56
*/
-int sun4i_hash_update(struct ahash_request *areq)
+int sun4i_hash(struct ahash_request *areq)
{
u32 v, ivmode = 0;
unsigned int i = 0;
@@ -180,22 +183,30 @@ int sun4i_hash_update(struct ahash_request *areq)
u32 spaces, rx_cnt = SS_RX_DEFAULT;
size_t copied = 0;
struct sg_mapping_iter mi;
+ unsigned int j = 0;
+ int zeros;
+ unsigned int index, padlen;
+ __be64 bits;
+ u32 bf[32];
+ u32 wb = 0;
+ unsigned int nwait, nbw = 0;
+ struct scatterlist *in_sg = areq->src;
dev_dbg(ss->dev, "%s %s bc=%llu len=%u mode=%x wl=%u h0=%0x",
__func__, crypto_tfm_alg_name(areq->base.tfm),
op->byte_count, areq->nbytes, op->mode,
op->len, op->hash[0]);
- if (areq->nbytes == 0)
+ if (unlikely(areq->nbytes == 0) && (op->flags & SS_HASH_FINAL) == 0)
return 0;
/* protect against overflow */
- if (areq->nbytes > UINT_MAX - op->len) {
+ if (unlikely(areq->nbytes > UINT_MAX - op->len)) {
dev_err(ss->dev, "Cannot process too large request\n");
return -EINVAL;
}
- if (op->len + areq->nbytes < 64) {
+ if (op->len + areq->nbytes < 64 && (op->flags & SS_HASH_FINAL) == 0) {
/* linearize data to op->buf */
copied = sg_pcopy_to_buffer(areq->src, sg_nents(areq->src),
op->buf + op->len, areq->nbytes, 0);
@@ -203,14 +214,6 @@ int sun4i_hash_update(struct ahash_request *areq)
return 0;
}
- end = ((areq->nbytes + op->len) / 64) * 64 - op->len;
-
- if (end > areq->nbytes || areq->nbytes - end > 63) {
- dev_err(ss->dev, "ERROR: Bound error %u %u\n",
- end, areq->nbytes);
- return -EINVAL;
- }
-
spin_lock_bh(&ss->slock);
/*
@@ -225,6 +228,33 @@ int sun4i_hash_update(struct ahash_request *areq)
/* Enable the device */
writel(op->mode | SS_ENABLED | ivmode, ss->base + SS_CTL);
+ if ((op->flags & SS_HASH_UPDATE) == 0)
+ goto hash_final;
+
+ /* start of handling data */
+ if ((op->flags & SS_HASH_FINAL) == 0) {
+ end = ((areq->nbytes + op->len) / 64) * 64 - op->len;
+
+ if (end > areq->nbytes || areq->nbytes - end > 63) {
+ dev_err(ss->dev, "ERROR: Bound error %u %u\n",
+ end, areq->nbytes);
+ return -EINVAL;
+ }
+ } else {
+ /* Since we have the flag final, we can go up to modulo 4 */
+ end = ((areq->nbytes + op->len) / 4) * 4 - op->len;
+ }
+
+ /* TODO if SGlen % 4 and op->len == 0 then DMA */
+ i = 1;
+ while (in_sg && i == 1) {
+ if ((in_sg->length % 4) != 0)
+ i = 0;
+ in_sg = sg_next(in_sg);
+ }
+ if (i == 1 && op->len == 0)
+ dev_dbg(ss->dev, "We can DMA\n");
+
i = 0;
sg_miter_start(&mi, areq->src, sg_nents(areq->src),
SG_MITER_FROM_SG | SG_MITER_ATOMIC);
@@ -285,7 +315,11 @@ int sun4i_hash_update(struct ahash_request *areq)
}
}
} while (i < end);
- /* final linear */
+
+ /*
+ * Now we have written to the device all that we can,
+ * store the remaining bytes in op->buf
+ */
if ((areq->nbytes - i) < 64) {
while (i < areq->nbytes && in_i < mi.length && op->len < 64) {
/* how many bytes we can read from current SG */
@@ -304,13 +338,21 @@ int sun4i_hash_update(struct ahash_request *areq)
sg_miter_stop(&mi);
+ /*
+ * End of data process
+ * Now if we have the flag final go to finalize part
+ * If not, store the partial hash
+ */
+ if ((op->flags & SS_HASH_FINAL) > 0)
+ goto hash_final;
+
writel(op->mode | SS_ENABLED | SS_DATA_END, ss->base + SS_CTL);
i = 0;
do {
v = readl(ss->base + SS_CTL);
i++;
} while (i < SS_TIMEOUT && (v & SS_DATA_END) > 0);
- if (i >= SS_TIMEOUT) {
+ if (unlikely(i >= SS_TIMEOUT)) {
dev_err_ratelimited(ss->dev,
"ERROR: hash end timeout %d>%d ctl=%x len=%u\n",
i, SS_TIMEOUT, v, areq->nbytes);
@@ -318,56 +360,24 @@ int sun4i_hash_update(struct ahash_request *areq)
goto release_ss;
}
- /* get the partial hash only if something was written */
for (i = 0; i < crypto_ahash_digestsize(tfm) / 4; i++)
op->hash[i] = readl(ss->base + SS_MD0 + i * 4);
-release_ss:
- writel(0, ss->base + SS_CTL);
- spin_unlock_bh(&ss->slock);
- return err;
-}
+ goto release_ss;
/*
- * sun4i_hash_final: finalize hashing operation
+ * hash_final: finalize hashing operation
*
* If we have some remaining bytes, we write them.
* Then ask the SS for finalizing the hashing operation
*
* I do not check RX FIFO size in this function since the size is 32
* after each enabling and this function neither write more than 32 words.
+ * If we come from the update part, we cannot have more than
+ * 3 remainings bytes to write and SS is fast enought to not care about it.
*/
-int sun4i_hash_final(struct ahash_request *areq)
-{
- u32 v, ivmode = 0;
- unsigned int i;
- unsigned int j = 0;
- int zeros, err = 0;
- unsigned int index, padlen;
- __be64 bits;
- struct sun4i_req_ctx *op = ahash_request_ctx(areq);
- struct sun4i_ss_ctx *ss = op->ss;
- struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
- u32 bf[32];
- u32 wb = 0;
- unsigned int nwait, nbw = 0;
- dev_dbg(ss->dev, "%s: byte=%llu len=%u mode=%x wl=%u h=%x",
- __func__, op->byte_count, areq->nbytes, op->mode,
- op->len, op->hash[0]);
-
- spin_lock_bh(&ss->slock);
-
- /*
- * if we have already written something,
- * restore the partial hash state
- */
- if (op->byte_count > 0) {
- ivmode = SS_IV_ARBITRARY;
- for (i = 0; i < crypto_ahash_digestsize(tfm) / 4; i++)
- writel(op->hash[i], ss->base + SS_IV0 + i * 4);
- }
- writel(op->mode | SS_ENABLED | ivmode, ss->base + SS_CTL);
+hash_final:
/* write the remaining words of the wait buffer */
if (op->len > 0) {
@@ -436,7 +446,7 @@ int sun4i_hash_final(struct ahash_request *areq)
v = readl(ss->base + SS_CTL);
i++;
} while (i < SS_TIMEOUT && (v & SS_DATA_END) > 0);
- if (i >= SS_TIMEOUT) {
+ if (unlikely(i >= SS_TIMEOUT)) {
dev_err_ratelimited(ss->dev,
"ERROR: hash end timeout %d>%d ctl=%x len=%u\n",
i, SS_TIMEOUT, v, areq->nbytes);
@@ -463,30 +473,41 @@ release_ss:
return err;
}
+int sun4i_hash_final(struct ahash_request *areq)
+{
+ struct sun4i_req_ctx *op = ahash_request_ctx(areq);
+
+ op->flags = SS_HASH_FINAL;
+ return sun4i_hash(areq);
+}
+
+int sun4i_hash_update(struct ahash_request *areq)
+{
+ struct sun4i_req_ctx *op = ahash_request_ctx(areq);
+
+ op->flags = SS_HASH_UPDATE;
+ return sun4i_hash(areq);
+}
+
/* sun4i_hash_finup: finalize hashing operation after an update */
int sun4i_hash_finup(struct ahash_request *areq)
{
- int err;
-
- err = sun4i_hash_update(areq);
- if (err != 0)
- return err;
+ struct sun4i_req_ctx *op = ahash_request_ctx(areq);
- return sun4i_hash_final(areq);
+ op->flags = SS_HASH_UPDATE | SS_HASH_FINAL;
+ return sun4i_hash(areq);
}
/* combo of init/update/final functions */
int sun4i_hash_digest(struct ahash_request *areq)
{
int err;
+ struct sun4i_req_ctx *op = ahash_request_ctx(areq);
err = sun4i_hash_init(areq);
if (err != 0)
return err;
- err = sun4i_hash_update(areq);
- if (err != 0)
- return err;
-
- return sun4i_hash_final(areq);
+ op->flags = SS_HASH_UPDATE | SS_HASH_FINAL;
+ return sun4i_hash(areq);
}
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h b/drivers/crypto/sunxi-ss/sun4i-ss.h
index 8e9c05f..ece5a1c 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -164,6 +164,7 @@ struct sun4i_req_ctx {
char buf[64];
unsigned int len;
struct sun4i_ss_ctx *ss;
+ int flags;
};
int sun4i_hash_crainit(struct crypto_tfm *tfm);
--
2.7.3
^ permalink raw reply related
* [PATCH] crypto: fix a little typo
From: LABBE Corentin @ 2016-08-10 9:29 UTC (permalink / raw)
To: herbert; +Cc: linux-crypto, linux-kernel, LABBE Corentin
The sentence 'Based on' is misspelled, respell it.
Signed-off-by: LABBE Corentin <clabbe.montjoie@gmail.com>
---
crypto/xts.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/xts.c b/crypto/xts.c
index 26ba583..305343f 100644
--- a/crypto/xts.c
+++ b/crypto/xts.c
@@ -5,7 +5,7 @@
*
* Copyright (c) 2007 Rik Snel <rsnel@cube.dyndns.org>
*
- * Based om ecb.c
+ * Based on ecb.c
* Copyright (c) 2006 Herbert Xu <herbert@gondor.apana.org.au>
*
* This program is free software; you can redistribute it and/or modify it
--
2.7.3
^ permalink raw reply related
* How best to {en,de}crypt between sk_buff and iov_iter?
From: David Howells @ 2016-08-10 9:12 UTC (permalink / raw)
To: netdev, linux-crypto; +Cc: dhowells, viro
Is there a good way to encrypt data held in an iov_iter directly into an
sk_buff and decrypt data held in an sk_buff back into an iov_iter?
What I would like to avoid is:
(a) Invoking skb_cow_data() to potentially take an unnecessary copy of the
data I shouldn't need to change, but I need to do this to decrypt in
place.
(b) Having to copy the unencrypted data between the sk_buff and the iov_iter
when the crypto process ought to get me a free copy.
One problem, though, is that I might not be able to do drain/fill a complete
sk_buff in a single operation because the iov_iter might not give me sufficient
bufferage/data to do that, so it may take multiple operations. However, since
I'm using an skcipher, I think it should be fine to call
crypto_skcipher_encrypt() multiple times on the same skcipher.
I can see a couple of alternatives:
(1) Duplicate skb_copy_datagram_iter(), give it an initialised
skcipher_request and let it set the crypto parameters for each block it
transfers. copy_to_iter() would then need to be replaced with something
that sets up an sglist each time from the iov.
Something similar would need doing for skb_copy_datagram_from_iter().
(2) Create an sglist for the skb and one for the iov_iter and encrypt/decrypt
between them. Unfortunately, if the iov_iter is a userspace reference
then this would mean pinning userspace pages.
(3) Add an {en,de}crypt-to-iov_iter capability to the crypto layer. I'm not
sure how well this would work for hardware support, though. I think we'd
come back to pinning userspace pages.
David
^ permalink raw reply
* RE: [PATCH 2/2] ath9k: disable RNG by default
From: Pan, Miaoqing @ 2016-08-10 7:43 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall,
miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org, Valo, Kalle,
linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
ath9k-devel, linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org, Sepehrdad, Pouyan
In-Reply-To: <1e8e88ad7de64c528f08c75ff9176ab8-fhY3XlRGNI1pWAYlkNb9jaRtKmQZhJ7pQQ4Iyu8u01E@public.gmane.org>
Hi Stephan,
The problem with using the add_device_randomness is that we do not know when to call that API, and we have to make our solution either timer-based or interrupt based, which is not really the correct way of implementing this feature.
Thanks,
Miaoqing
-----Original Message-----
From: Pan, Miaoqing
Sent: Wednesday, August 10, 2016 3:41 PM
To: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
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