Re: [PATCH 2/2] ath9k: disable RNG by default

[Pan, Miaoqing]

Hi Stephan,

For those less perfect noise source, can't pass the FIPS test.

static int update_kernel_random(int random_step,
unsigned char *buf, fips_ctx_t *fipsctx_in)
{
unsigned char *p; 
int fips;

fips = fips_run_rng_test(fipsctx_in, buf);
if (fips)
return 1;

for (p = buf; p + random_step <= [FIPS_RNG_BUFFER_SIZE];
 p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}

--
Miaoqing

From: Stephan Mueller 
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoq...@codeaurora.org; Valo, Kalle; 
linux-wirel...@vger.kernel.org; ath9k-devel; linux-crypto@vger.kernel.org; 
ja...@lakedaemon.net; Sepehrdad, Pouyan
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default

Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
>
> Please elaborate.

in rngd_linux.c:random_add_entropy(void *buf, size_t size):

entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);

if (ioctl(random_fd, RNDADDENTROPY, ) != 0) {

...


in rngd.c:do_loop():

retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
 buf, iter->fipsctx);

where update_kernel_random simply invokes random_add_entropy in chunks.

Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.

With less than perfect noise sources, entropy.ent_count should be much
smaller.
>
> Thanks,



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Keith Packard]

Henrique de Moraes Holschuh  writes:

> IMHO, this is mightly annoying to use from inside a rngd-like utility in
> a race-free, safe way.  It looks to me that ioctl() would be a much
> better interface for everything but the "enabled" functionality (which
> should be reported to the rngd-like utility as open() on the real device
> failing with, e.g., ENXIO, when that source is disabled).

What information does an rngd-like program actually want? All I can
think that it would need is the stream of random data. I guess some
estimate of the entropy available would be nice, but surely it would
want to verify that in any case.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH

[Mat Martineau]

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 
+#include 


These may belong at the top of the file, even if they are only used when 
CONFIG_KEY_DH_OPERATIONS is defined.



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

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3] DH support: add KDF handling support

[Mat Martineau]

On Sat, 6 Aug 2016, Stephan Mueller wrote:


diff --git a/man/keyctl_dh_compute.3 b/man/keyctl_dh_compute.3
index b06d39e..92d358f 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_dy_compute ().


Minor typo: dy->dh


Regards,

--
Mat Martineau
Intel OTC
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

[Tapas Sarangi]

Hi Stephan,

Thanks. The patch that I applied have different line numbers than yours.
In any case, patch worked to get rid of Œdrbg¹ related error.

Now, fips mode is failing on self-test:

/boot/vmlinuz-4.7.0-1.tos2_5: OK
[1.296714] alg: skcipher: setkey failed on test 1 for xts(aes-asm):
flags=10
[1.297665] Kernel panic - not syncing: xts(aes): xts(aes) alg self
test failed in fips mode!
[1.297665]




Thanks
-Tapas



On 8/9/16, 2:02 PM, "Stephan Mueller"  wrote:

>Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:
>
>Hi Tapas,
>
>I think I found the issue. Can you please test the attached patch?
>
>---8<---
>
>When calling the DRBG health test in FIPS mode, the Jitter RNG is not
>yet present in the kernel crypto API which will cause the instantiation
>to fail and thus the health test to fail.
>
>As the health tests cover the enforcement of various thresholds, invoke
>the functions that are supposed to enforce the thresholds directly.
>
>This patch also saves precious seed.
>
>Reported-by: Tapas Sarangi 
>Signed-off-by: Stephan Mueller 
>---
> crypto/drbg.c | 15 ---
> 1 file changed, 4 insertions(+), 11 deletions(-)
>
>diff --git a/crypto/drbg.c b/crypto/drbg.c
>index f752da3..edf3ce0 100644
>--- a/crypto/drbg.c
>+++ b/crypto/drbg.c
>@@ -1917,6 +1917,8 @@ static inline int __init
>drbg_healthcheck_sanity(void)
>   return -ENOMEM;
>
>   mutex_init(>drbg_mutex);
>+  drbg->core = _cores[coreref];
>+  drbg->reseed_threshold = drbg_max_requests(drbg);
>
>   /*
>* if the following tests fail, it is likely that there is a buffer
>@@ -1926,12 +1928,6 @@ static inline int __init
>drbg_healthcheck_sanity(void)
>* grave bug.
>*/
>
>-  /* get a valid instance of DRBG for following tests */
>-  ret = drbg_instantiate(drbg, NULL, coreref, pr);
>-  if (ret) {
>-  rc = ret;
>-  goto outbuf;
>-  }
>   max_addtllen = drbg_max_addtl(drbg);
>   max_request_bytes = drbg_max_request_bytes(drbg);
>   drbg_string_fill(, buf, max_addtllen + 1);
>@@ -1941,10 +1937,9 @@ static inline int __init
>drbg_healthcheck_sanity(void)
>   /* overflow max_bits */
>   len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
>   BUG_ON(0 < len);
>-  drbg_uninstantiate(drbg);
>
>   /* overflow max addtllen with personalization string */
>-  ret = drbg_instantiate(drbg, , coreref, pr);
>+  ret = drbg_seed(drbg, , false);
>   BUG_ON(0 == ret);
>   /* all tests passed */
>   rc = 0;
>@@ -1952,9 +1947,7 @@ static inline int __init
>drbg_healthcheck_sanity(void)
>   pr_devel("DRBG: Sanity tests for failure code paths successfully "
>"completed\n");
>
>-  drbg_uninstantiate(drbg);
>-outbuf:
>-  kzfree(drbg);
>+  kfree(drbg);
>   return rc;
> }
>
>--
>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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Henrique de Moraes Holschuh]

On Tue, 09 Aug 2016, Jason Cooper wrote:
> Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

IMHO, this is mightly annoying to use from inside a rngd-like utility in
a race-free, safe way.  It looks to me that ioctl() would be a much
better interface for everything but the "enabled" functionality (which
should be reported to the rngd-like utility as open() on the real device
failing with, e.g., ENXIO, when that source is disabled).

-- 
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: DRBG: do not call drbg_instantiate in healt test

[Stephan Mueller]

Am Dienstag, 9. August 2016, 19:52:46 CEST schrieb Stephan Mueller:

Hi Tapas,

I think I found the issue. Can you please test the attached patch?

---8<---

When calling the DRBG health test in FIPS mode, the Jitter RNG is not
yet present in the kernel crypto API which will cause the instantiation
to fail and thus the health test to fail.

As the health tests cover the enforcement of various thresholds, invoke
the functions that are supposed to enforce the thresholds directly.

This patch also saves precious seed.

Reported-by: Tapas Sarangi 
Signed-off-by: Stephan Mueller 
---
 crypto/drbg.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index f752da3..edf3ce0 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -1917,6 +1917,8 @@ static inline int __init drbg_healthcheck_sanity(void)
return -ENOMEM;
 
mutex_init(>drbg_mutex);
+   drbg->core = _cores[coreref];
+   drbg->reseed_threshold = drbg_max_requests(drbg);
 
/*
 * if the following tests fail, it is likely that there is a buffer
@@ -1926,12 +1928,6 @@ static inline int __init drbg_healthcheck_sanity(void)
 * grave bug.
 */
 
-   /* get a valid instance of DRBG for following tests */
-   ret = drbg_instantiate(drbg, NULL, coreref, pr);
-   if (ret) {
-   rc = ret;
-   goto outbuf;
-   }
max_addtllen = drbg_max_addtl(drbg);
max_request_bytes = drbg_max_request_bytes(drbg);
drbg_string_fill(, buf, max_addtllen + 1);
@@ -1941,10 +1937,9 @@ static inline int __init drbg_healthcheck_sanity(void)
/* overflow max_bits */
len = drbg_generate(drbg, buf, (max_request_bytes + 1), NULL);
BUG_ON(0 < len);
-   drbg_uninstantiate(drbg);
 
/* overflow max addtllen with personalization string */
-   ret = drbg_instantiate(drbg, , coreref, pr);
+   ret = drbg_seed(drbg, , false);
BUG_ON(0 == ret);
/* all tests passed */
rc = 0;
@@ -1952,9 +1947,7 @@ static inline int __init drbg_healthcheck_sanity(void)
pr_devel("DRBG: Sanity tests for failure code paths successfully "
 "completed\n");
 
-   drbg_uninstantiate(drbg);
-outbuf:
-   kzfree(drbg);
+   kfree(drbg);
return rc;
 }
 
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Keith Packard]

Jason Cooper  writes:

> On another thread, regarding the ath9k-rng (actually just the adc
> registers), Henrique asked about per-source knobs.  My suggestion
> follows from that.

I'd do that with the source-specific driver instead of attempting to
route controls through hwrng. Anything else seems like 'ioctl' to me.

> Sure, but /dev/hwrng is a user interface.  Typically to rngd, but not
> necessarily.  We need to make sure it's behavior is consistent with
> existing expectations.

Hrm. Maybe /dev/hwrng should use a different policy than how we feed
/dev/random -- we could use the existing behaviour for /dev/hwrng, but
use a round-robin for /dev/random. That way, the latest device would
always end up in /dev/hwrng (unless configured otherwise), and we'd
still use all of the available sources to help stir the kernel entropy
pool.

> We shouldn't attach first-probed to /dev/hwrng, because that may not be
> what the user is expecting.  If I bought a raw entropy source, and knew
> nothing of the proposed multi-source interfaces, I'd expect the USB
> dongle to be attached to /dev/hwrng.  Despite the fact that my pcie wifi
> card was probed first and has adc registers providing an entropy source.

That seems like a fragile interface as it depends on discovery order,
but it is what we have currently.

The chaoskey driver also exposes it's own device; that provides a simple
way to ensure that the application is getting bits from the desired
entropy source.

> I'm not sure how we ensure that.  Perhaps an 'environmental' flag in the
> hw_random source attributes?  Or a 'not-designed-to-be-an-rng' flag? :)
> Maybe those would be /dev/envrng[0-9]...

Or some set of query ioctls on /dev/hwrng[0-9]+ that would provide
information about the capabilities of the underlying device.

There are lots of things we could do, I guess the question I have is how
much of this would applications actually use effectively? You're
probably right that /dev/hwrng should point at a single source and not
change though; otherwise figuring out what the quality of the bits
you're getting isn't possible.x

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Jason Cooper]

Hi Keith,

On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper  writes:
> > Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> > sysfs interface for per device quality, rate, and enabled attributes.
> > e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}
> 
> I was interested in the data being provided for /dev/random; that seems
> like the most important interface to me.

Me too, agreed.

> But, exposing all of the devices using consistent names does seem like
> a useful idea at some level.

On another thread, regarding the ath9k-rng (actually just the adc
registers), Henrique asked about per-source knobs.  My suggestion
follows from that.

> > /dev/hwrng could pull from the one with the highest quality, or user
> > specified for backwards compatibility.
> 
> I like the notion of using all of them in turn; if one of them turns out
> to be broken, you're still stirring in data from the others. After all,
> the quality metric is provided by the device, we aren't doing any
> analysis on the data to determine it independently.

Sure, but /dev/hwrng is a user interface.  Typically to rngd, but not
necessarily.  We need to make sure it's behavior is consistent with
existing expectations.

We shouldn't attach first-probed to /dev/hwrng, because that may not be
what the user is expecting.  If I bought a raw entropy source, and knew
nothing of the proposed multi-source interfaces, I'd expect the USB
dongle to be attached to /dev/hwrng.  Despite the fact that my pcie wifi
card was probed first and has adc registers providing an entropy source.

I'm not sure how we ensure that.  Perhaps an 'environmental' flag in the
hw_random source attributes?  Or a 'not-designed-to-be-an-rng' flag? :)
Maybe those would be /dev/envrng[0-9]...

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Keith Packard]

Jason Cooper  writes:

> Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
> sysfs interface for per device quality, rate, and enabled attributes.
> e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

I was interested in the data being provided for /dev/random; that seems
like the most important interface to me.  But, exposing all of the
devices using consistent names does seem like a useful idea at some
level.

> /dev/hwrng could pull from the one with the highest quality, or user
> specified for backwards compatibility.

I like the notion of using all of them in turn; if one of them turns out
to be broken, you're still stirring in data from the others. After all,
the quality metric is provided by the device, we aren't doing any
analysis on the data to determine it independently.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

Hi Henrique,

On Tue, Aug 09, 2016 at 07:24:58AM -0300, Henrique de Moraes Holschuh wrote:
> On Tue, 09 Aug 2016, Stephan Mueller wrote:
> > RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools 
> > then 
> > broken (at least in those large distros)?
> 
> Might I humbly suggest that the kernel start providing some metatada
> about the quality of the random source that userspace can consume?
> Preferably by a new ioctl, so that it will fit naturally if we ever
> extend /dev/hwrng to support more than one source?
> 
> That would allow for auto tunning to be implemented in userspace...

See my reply to Keith Packard's proposed multi-device hw_random patch:

  https://lkml.kernel.org/r/20160809165710.gc2...@io.lakedaemon.net

and top of thread:

  https://lkml.kernel.org/r/1469477255-26824-1-git-send-email-kei...@keithp.com

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

[Stephan Mueller]

Am Dienstag, 9. August 2016, 17:11:09 CEST schrieb Tapas Sarangi:

Hi Tapas, Herbert,

> Hi Stephan,
> 
> Thanks. I have already tried that. ‘drbg’ module is loaded fine in a
> non-fips mode. Here are output from some commands.

There is something strange going on. I have to compile the DRBG statically. 
When booting the kernel with fips=1 (of course after changing the key size to 
2k or 3k in certs/x509.genkey), the DRBG does not show up in /proc/crypto nor 
can I find testmgr entries about the DRBG.

When I reboot the kernel without fips=1, all works as expected.

When I create a copy of the drbg.c code and have it compiled as a module to 
ensure it is signed, I can insmod it and the testmgr successfully tests it.

Note, with fips=1, my kernel crashes randomly somewhere in the elf loading 
code -- I guess it is because there is no stdrng.

> 
> I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am
> not using that, could that be a problem ?

Nope, this LRNG is something completely different -- it is my proposal to 
replace the current /dev/random and /dev/urandom implementation as documented 
in [1].

[1] http://www.chronox.de/lrng.html

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Jason Cooper]

On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoq...@codeaurora.org wrote:
> From: Miaoqing Pan 
> 
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
> 
> Signed-off-by: Miaoqing Pan 

Until we get the hw_random/get_device_randomness question sorted...

Reviewed-by: Jason Cooper 

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

[Tapas Sarangi]

Hi Stephan,

Thanks. I have already tried that. ‘drbg’ module is loaded fine in a
non-fips mode. Here are output from some commands.

I see that at some point you had a patch to use CONFIG_CRYPTO_LRNG. I am
not using that, could that be a problem ?

-Tapas


[root@localhost ~]# modprobe drbg
[root@localhost ~]# echo $?
0

[root@localhost ~]# dmesg | tail -5
[3.636174] nf_conntrack version 0.5.0 (7168 buckets, 28672 max)
[3.738645] NET: Registered protocol family 10
[3.743004] ip6_tables: (C) 2000-2006 Netfilter Core Team
[3.773384] input: ImExPS/2 BYD TouchPad as
/devices/platform/i8042/serio1/input/input3
[3.776803] mousedev: PS/2 mouse device common for all mice

[root@localhost ~]# lsmod | grep drbg
drbg   14147  1

[root@localhost ~]# modinfo drbg
filename:   /lib/modules/4.7.0-1.tos2_5/kernel/crypto/drbg.ko.gz
alias:  crypto-stdrng
alias:  stdrng
description:NIST SP800-90A Deterministic Random Bit Generator (DRBG)
using following cores: HMAC
author: Stephan Mueller 
license:GPL
alias:  crypto-drbg_nopr_hmac_sha1
alias:  drbg_nopr_hmac_sha1
alias:  crypto-drbg_pr_hmac_sha1
alias:  drbg_pr_hmac_sha1
alias:  crypto-drbg_nopr_hmac_sha256
alias:  drbg_nopr_hmac_sha256
alias:  crypto-drbg_pr_hmac_sha256
alias:  drbg_pr_hmac_sha256
alias:  crypto-drbg_nopr_hmac_sha384
alias:  drbg_nopr_hmac_sha384
alias:  crypto-drbg_pr_hmac_sha384
alias:  drbg_pr_hmac_sha384
alias:  crypto-drbg_nopr_hmac_sha512
alias:  drbg_nopr_hmac_sha512
alias:  crypto-drbg_pr_hmac_sha512
alias:  drbg_pr_hmac_sha512
depends:
intree: Y
vermagic:   4.7.0-1.tos2_5 SMP mod_unload modversions







On 8/9/16, 12:05 PM, "Stephan Mueller"  wrote:

>Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi:
>
>Hi Tapas,
>
>> Hi Stephan,
>>
>> Following up from the other thread:
>>
>> While trying to boot in FIPS mode, kernel panics with the following
>> message. So far, I don¹t have success to get more information about
>>which
>> module or symbol is causing this. I haven¹t found any errors or warnings
>> in kernel compilation. It boots fine in a non-fips mode.
>>
>> I am also pasting the CRYPTO related configs that I have enabled (See
>> below).
>
>I do not see the issue immediately. Could you boot without fips=1 and do
>a
>modprobe drbg ?
>
>I am also testing fips=1 now.
>
>Ciao
>Stephan




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.

Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'

[Stephan Mueller]

Am Dienstag, 9. August 2016, 16:34:59 CEST schrieb Tapas Sarangi:

Hi Tapas,

> Hi Stephan,
> 
> Following up from the other thread:
> 
> While trying to boot in FIPS mode, kernel panics with the following
> message. So far, I don¹t have success to get more information about which
> module or symbol is causing this. I haven¹t found any errors or warnings
> in kernel compilation. It boots fine in a non-fips mode.
> 
> I am also pasting the CRYPTO related configs that I have enabled (See
> below).

I do not see the issue immediately. Could you boot without fips=1 and do a 
modprobe drbg ?

I am also testing fips=1 now.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Jason Cooper]

Hi Keith, Herbert,

On Tue, Aug 09, 2016 at 05:50:58PM +0800, Herbert Xu wrote:
> On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> > Instead of having only one hwrng feeding /dev/random at a time, maintain
> > a list of devices and cycle between them when filling the entropy pool.
> > 
> > Signed-off-by: Keith Packard 
> 
> So you're cycling RNGs even for user-space reads? That could be
> problematic because not all hardware RNGs carry the maximum amount
> of entropy.  It would be rather annoying to be cycling between
> RNGs of different qualities.
> 
> Perhaps only cycle for the kernel hwrngd?

Perhaps a /dev/hwrng[0-9] per rng?  That would lend itself nicely to a
sysfs interface for per device quality, rate, and enabled attributes.
e.g. /sys/class/hw_random/hwrng0/{device/,quality,rate,enabled}

/dev/hwrng could pull from the one with the highest quality, or user
specified for backwards compatibility.

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

FIPS mode: modprobe: ERROR: could not insert 'drbg'

[Tapas Sarangi]

Hi Stephan,

Following up from the other thread:

While trying to boot in FIPS mode, kernel panics with the following
message. So far, I don¹t have success to get more information about which
module or symbol is causing this. I haven¹t found any errors or warnings
in kernel compilation. It boots fine in a non-fips mode.

I am also pasting the CRYPTO related configs that I have enabled (See
below).

-Tapas

/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
unknown parameter (see dmesg)
[1.330798] dracut: FATAL: FIPS integrity test failed
[1.331534] dracut: Refusing to continue


[1.333491] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0100
[1.333491]
[1.334768] CPU: 0 PID: 1 Comm: init Not tainted 4.7.0-1.tos2_5 #1
[1.335632] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.8.2-20150714_191134- 04/01/2014
[1.336114]   88003e1dfbc8 812ae299
0001
[1.336114]  0001 81716b00 88003e21
88003e1dfc48
[1.336114]  81104fd4 0010 88003e1dfc58
88003e1dfbf8
[1.336114] Call Trace:
[1.336114]  [] dump_stack+0x51/0x78
[1.336114]  [] panic+0xc1/0x211
[1.336114]  [] forget_original_parent+0x411/0x420
[1.336114]  [] ? perf_pin_task_context+0x12/0x40
[1.336114]  [] ? perf_event_exit_task+0x3b2/0x470
[1.336114]  [] exit_notify+0x36/0x1e0
[1.336114]  [] ? cgroup_exit+0x71/0xc0
[1.336114]  [] ? task_work_run+0x5f/0x90
[1.336114]  [] do_exit+0x31f/0x640
[1.336114]  [] ? fput+0x9/0x10
[1.336114]  [] ? task_work_run+0x5f/0x90
[1.336114]  [] ? __do_page_fault+0x17e/0x450
[1.336114]  [] do_group_exit+0x49/0xb0
[1.336114]  [] SyS_exit_group+0x12/0x20
[1.336114]  [] entry_SYSCALL_64_fastpath+0x13/0x8f
[1.336114] Kernel Offset: disabled
[1.336114] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x0100
[1.336114]



# Enabled CRYPTO configs
[root@localhost ~]# egrep 'CRYPTO.*=y|CRYPTO.*=m'
/boot/config-4.7.0-1.tos2_5
CONFIG_BLK_DEV_CRYPTOLOOP=m
CONFIG_RT2X00_LIB_CRYPTO=y
CONFIG_CRYPTO=y
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=m
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
CONFIG_CRYPTO_USER=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_NULL2=y
CONFIG_CRYPTO_PCRYPT=m
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_MCRYPTD=m
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_TEST=m
CONFIG_CRYPTO_ABLK_HELPER=m
CONFIG_CRYPTO_GLUE_HELPER_X86=m
CONFIG_CRYPTO_CCM=m
CONFIG_CRYPTO_GCM=m
CONFIG_CRYPTO_SEQIV=m
CONFIG_CRYPTO_ECHAINIV=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_CTR=m
CONFIG_CRYPTO_CTS=m
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=m
CONFIG_CRYPTO_PCBC=m
CONFIG_CRYPTO_XTS=m
CONFIG_CRYPTO_CMAC=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_VMAC=m
CONFIG_CRYPTO_CRC32C=y
CONFIG_CRYPTO_CRC32C_INTEL=m
CONFIG_CRYPTO_CRC32=m
CONFIG_CRYPTO_CRC32_PCLMUL=m
CONFIG_CRYPTO_CRCT10DIF=y
CONFIG_CRYPTO_CRCT10DIF_PCLMUL=m
CONFIG_CRYPTO_GHASH=m
CONFIG_CRYPTO_MD4=m
CONFIG_CRYPTO_MD5=y
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_RMD128=m
CONFIG_CRYPTO_RMD160=m
CONFIG_CRYPTO_RMD256=m
CONFIG_CRYPTO_RMD320=m
CONFIG_CRYPTO_SHA1=y
CONFIG_CRYPTO_SHA1_SSSE3=m
CONFIG_CRYPTO_SHA256_SSSE3=m
CONFIG_CRYPTO_SHA512_SSSE3=m
CONFIG_CRYPTO_SHA1_MB=m
CONFIG_CRYPTO_SHA256=y
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL=m
CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=m
CONFIG_CRYPTO_AES_NI_INTEL=m
CONFIG_CRYPTO_ANUBIS=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_BLOWFISH_COMMON=m
CONFIG_CRYPTO_BLOWFISH_X86_64=m
CONFIG_CRYPTO_CAMELLIA=m
CONFIG_CRYPTO_CAMELLIA_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64=m
CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64=m
CONFIG_CRYPTO_CAST_COMMON=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST5_AVX_X86_64=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_CAST6_AVX_X86_64=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_DES3_EDE_X86_64=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_SALSA20=m
CONFIG_CRYPTO_SALSA20_X86_64=m
CONFIG_CRYPTO_SEED=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_SERPENT_SSE2_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX_X86_64=m
CONFIG_CRYPTO_SERPENT_AVX2_X86_64=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_X86_64=m
CONFIG_CRYPTO_TWOFISH_X86_64_3WAY=m
CONFIG_CRYPTO_TWOFISH_AVX_X86_64=m
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_LZO=m
CONFIG_CRYPTO_LZ4=m
CONFIG_CRYPTO_LZ4HC=m
CONFIG_CRYPTO_ANSI_CPRNG=m
CONFIG_CRYPTO_DRBG_MENU=m
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG=m

Re: RSA key size not allowed in FIPS

[Stephan Mueller]

Am Dienstag, 9. August 2016, 16:07:06 CEST schrieb Tapas Sarangi:

Hi Tapas,

> Hi Stephan,
> 
> 
> Thanks for your responses. I am past this error now.
> 
> I am still NOT out of trouble. Now, test integrity fails while trying to
> get into FIPS mode. Here is the snippet of error messages.  I will create
> a separate thread for this,
> 
> /boot/vmlinuz-4.7.0-1.tos2_5: OK
> modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
> unknown parameter (see dmesg)

Do you see which symbol is missing?


> [1.193406] dracut: FATAL: FIPS integrity test failed
> [1.194086] dracut: Refusing to continue
> 
> [1.195820] Kernel panic - not syncing: Attempted to kill init!
> exitcode=0x0100
> [1.195820]
> 
> 
> -Tapas
> 
> 
> 
> On 8/9/16, 10:00 AM, "Tapas Sarangi"  wrote:
> 
> 
> >Embarrassing! Yes, I just saw this while you are pressing send on that
> >replyŠ default bits were set to 4096 in x509.genkey. :-(
> >
> >I am trying out with 2048 bits. I will confirm.
> >
> >-Tapas
> >
> >
> >On 8/9/16, 9:55 AM, "Stephan Mueller"  wrote:
> >
> >
> >>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
> >>
> >>Hi Tapas, David,
> >>
> >>
> >>> Hi Stephan,
> >>>
> >>>
> >>>
> >>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
> >>> tells about the key size used.
> >>> I am using ³sha256². Initially, I was using ³sha512² which I thought
> >>>
> >>>could
> >>>
> >>> be causing problem, but I am getting same error when change it to
> >>> ³sha256².
> >>>
> >>>
> >>>
> >>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
> >>>
> >>>
> >>>
> >>> CONFIG_MODULE_SIG=y
> >>> # CONFIG_MODULE_SIG_FORCE is not set
> >>> CONFIG_MODULE_SIG_ALL=y
> >>> # CONFIG_MODULE_SIG_SHA1 is not set
> >>> # CONFIG_MODULE_SIG_SHA224 is not set
> >>> CONFIG_MODULE_SIG_SHA256=y
> >>> # CONFIG_MODULE_SIG_SHA384 is not set
> >>> # CONFIG_MODULE_SIG_SHA512 is not set
> >>> CONFIG_MODULE_SIG_HASH="sha256"
> >>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
> >>
> >>
> >>It is rather the question how signing_key.pem is generated.
> >>
> >>Do you have the file certs/x509.genkey? If yes, what is the default_bits
> >>value?
> >>
> >>David, the x509.genkey file seems to generate a 4k RSA key per default.
> >>This
> >>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
> >>
> >>Ciao
> >>Stephan
> >
> >
> 
> 
> 
> 
> 
> 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.



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RSA key size not allowed in FIPS

[Tapas Sarangi]

Hi Stephan,


Thanks for your responses. I am past this error now.

I am still NOT out of trouble. Now, test integrity fails while trying to
get into FIPS mode. Here is the snippet of error messages.  I will create
a separate thread for this,

/boot/vmlinuz-4.7.0-1.tos2_5: OK
modprobe: ERROR: could not insert 'drbg': Unknown symbol in module, or
unknown parameter (see dmesg)
[1.193406] dracut: FATAL: FIPS integrity test failed
[1.194086] dracut: Refusing to continue

[1.195820] Kernel panic - not syncing: Attempted to kill init!
exitcode=0x0100
[1.195820]


-Tapas



On 8/9/16, 10:00 AM, "Tapas Sarangi"  wrote:

>Embarrassing! Yes, I just saw this while you are pressing send on that
>replyŠ default bits were set to 4096 in x509.genkey. :-(
>
>I am trying out with 2048 bits. I will confirm.
>
>-Tapas
>
>
>On 8/9/16, 9:55 AM, "Stephan Mueller"  wrote:
>
>>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
>>
>>Hi Tapas, David,
>>
>>> Hi Stephan,
>>>
>>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
>>> tells about the key size used.
>>> I am using ³sha256². Initially, I was using ³sha512² which I thought
>>>could
>>> be causing problem, but I am getting same error when change it to
>>> ³sha256².
>>>
>>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>>>
>>> CONFIG_MODULE_SIG=y
>>> # CONFIG_MODULE_SIG_FORCE is not set
>>> CONFIG_MODULE_SIG_ALL=y
>>> # CONFIG_MODULE_SIG_SHA1 is not set
>>> # CONFIG_MODULE_SIG_SHA224 is not set
>>> CONFIG_MODULE_SIG_SHA256=y
>>> # CONFIG_MODULE_SIG_SHA384 is not set
>>> # CONFIG_MODULE_SIG_SHA512 is not set
>>> CONFIG_MODULE_SIG_HASH="sha256"
>>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>>
>>It is rather the question how signing_key.pem is generated.
>>
>>Do you have the file certs/x509.genkey? If yes, what is the default_bits
>>value?
>>
>>David, the x509.genkey file seems to generate a 4k RSA key per default.
>>This
>>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
>>
>>Ciao
>>Stephan
>




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.

Re: RSA key size not allowed in FIPS

[Tapas Sarangi]

Embarrassing! Yes, I just saw this while you are pressing send on that
replyŠ default bits were set to 4096 in x509.genkey. :-(

I am trying out with 2048 bits. I will confirm.

-Tapas


On 8/9/16, 9:55 AM, "Stephan Mueller"  wrote:

>Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:
>
>Hi Tapas, David,
>
>> Hi Stephan,
>>
>> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=³sha256")
>> tells about the key size used.
>> I am using ³sha256². Initially, I was using ³sha512² which I thought
>>could
>> be causing problem, but I am getting same error when change it to
>> ³sha256².
>>
>> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>>
>> CONFIG_MODULE_SIG=y
>> # CONFIG_MODULE_SIG_FORCE is not set
>> CONFIG_MODULE_SIG_ALL=y
>> # CONFIG_MODULE_SIG_SHA1 is not set
>> # CONFIG_MODULE_SIG_SHA224 is not set
>> CONFIG_MODULE_SIG_SHA256=y
>> # CONFIG_MODULE_SIG_SHA384 is not set
>> # CONFIG_MODULE_SIG_SHA512 is not set
>> CONFIG_MODULE_SIG_HASH="sha256"
>> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>
>It is rather the question how signing_key.pem is generated.
>
>Do you have the file certs/x509.genkey? If yes, what is the default_bits
>value?
>
>David, the x509.genkey file seems to generate a 4k RSA key per default.
>This
>will cause a panic with fips=1 as only 2k and 3k keys are allowed.
>
>Ciao
>Stephan




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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RSA key size not allowed in FIPS

[Stephan Mueller]

Am Dienstag, 9. August 2016, 14:39:03 CEST schrieb Tapas Sarangi:

Hi Tapas, David,

> Hi Stephan,
> 
> If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
> tells about the key size used.
> I am using “sha256”. Initially, I was using “sha512” which I thought could
> be causing problem, but I am getting same error when change it to
> “sha256”.
> 
> [root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
> 
> CONFIG_MODULE_SIG=y
> # CONFIG_MODULE_SIG_FORCE is not set
> CONFIG_MODULE_SIG_ALL=y
> # CONFIG_MODULE_SIG_SHA1 is not set
> # CONFIG_MODULE_SIG_SHA224 is not set
> CONFIG_MODULE_SIG_SHA256=y
> # CONFIG_MODULE_SIG_SHA384 is not set
> # CONFIG_MODULE_SIG_SHA512 is not set
> CONFIG_MODULE_SIG_HASH="sha256"
> CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"

It is rather the question how signing_key.pem is generated.

Do you have the file certs/x509.genkey? If yes, what is the default_bits 
value?

David, the x509.genkey file seems to generate a 4k RSA key per default. This 
will cause a panic with fips=1 as only 2k and 3k keys are allowed.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RSA key size not allowed in FIPS

[Tapas Sarangi]

Looking at the kernel compilation log, it seems to be generating a 4k
(4096 bits) private key, although I am specifying
CONFIG_MODULE_SIG_HASH=“sha256”. How can I generate RSA key that is within
2k-3k bits ?

Here is a snippet from the compilation log:

### Now generating an X.509 key pair to be used for signing modules.
###
### If this takes a long time, you might wish to run rngd in the
### background to keep the supply of entropy topped up.  It
### needs to be run as root, and uses a hardware random
### number generator if one is available.
###
Generating a 4096 bit RSA private key

Thanks a lot.
-Tapas





On 8/9/16, 9:39 AM, "Tapas Sarangi"  wrote:

>Hi Stephan,
>
>If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
>tells about the key size used.
>I am using “sha256”. Initially, I was using “sha512” which I thought could
>be causing problem, but I am getting same error when change it to
>“sha256”.
>
>[root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5
>
>CONFIG_MODULE_SIG=y
># CONFIG_MODULE_SIG_FORCE is not set
>CONFIG_MODULE_SIG_ALL=y
># CONFIG_MODULE_SIG_SHA1 is not set
># CONFIG_MODULE_SIG_SHA224 is not set
>CONFIG_MODULE_SIG_SHA256=y
># CONFIG_MODULE_SIG_SHA384 is not set
># CONFIG_MODULE_SIG_SHA512 is not set
>CONFIG_MODULE_SIG_HASH="sha256"
>CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
>
>Thanks
>
>
>-Tapas
>
>
>On 8/9/16, 9:29 AM, "Stephan Mueller"  wrote:
>
>>Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
>>
>>Hi Tapas,
>>
>>> Hello,
>>>
>>> I am using vanilla kernel-4.7 source. It crashes with the following
>>>when
>>> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
>>> argument.
>>
>>The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your
>>RSA
>>key used for signatures.
>>
>>/* In FIPS mode only allow key size 2K & 3K */
>>if (n_sz != 256 && n_sz != 384) {
>>pr_err("RSA: key size not allowed in FIPS
>>mode\n");
>>return -EINVAL;
>>}
>>
>>Ciao
>>Stephan
>




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.

Re: RSA key size not allowed in FIPS

[Tapas Sarangi]

Hi Stephan,

If I understand this correctly, this (CONFIG_MODULE_SIG_HASH=“sha256")
tells about the key size used.
I am using “sha256”. Initially, I was using “sha512” which I thought could
be causing problem, but I am getting same error when change it to
“sha256”.

[root@localhost ~]# grep MODULE_SIG /boot/config-4.7.0-1.tos2_5

CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"

Thanks


-Tapas


On 8/9/16, 9:29 AM, "Stephan Mueller"  wrote:

>Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:
>
>Hi Tapas,
>
>> Hello,
>>
>> I am using vanilla kernel-4.7 source. It crashes with the following when
>> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
>> argument.
>
>The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your
>RSA
>key used for signatures.
>
>/* In FIPS mode only allow key size 2K & 3K */
>if (n_sz != 256 && n_sz != 384) {
>pr_err("RSA: key size not allowed in FIPS
>mode\n");
>return -EINVAL;
>}
>
>Ciao
>Stephan




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.

Re: RSA key size not allowed in FIPS

[Gary R Hook]

On 08/09/2016 09:10 AM, Tapas Sarangi wrote:


Ps : I could not send any attachment, is it possible to send attachment to
this mailing list ?


Pretty sure that's frowned upon.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: RSA key size not allowed in FIPS

[Stephan Mueller]

Am Dienstag, 9. August 2016, 14:10:33 CEST schrieb Tapas Sarangi:

Hi Tapas,

> Hello,
> 
> I am using vanilla kernel-4.7 source. It crashes with the following when
> booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
> argument.

The kernel only allows 2k and 3k RSA keys in FIPS mode. Please check your RSA 
key used for signatures.

/* In FIPS mode only allow key size 2K & 3K */
if (n_sz != 256 && n_sz != 384) {
pr_err("RSA: key size not allowed in FIPS mode\n");
return -EINVAL;
}

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RSA key size not allowed in FIPS

[Tapas Sarangi]

Hello,

I am using vanilla kernel-4.7 source. It crashes with the following when
booted with ³fips=1 boot=/dev/sda1² option at the kernel command line
argument.

[0.642411] RSA: key size not allowed in FIPS mode
[0.643099] Problem loading in-kernel X.509 certificate (-22)
[0.800524] BUG: unable to handle kernel NULL pointer dereference at
0068
[0.803075] IP: [] kernfs_find_ns+0x17/0xf0
[0.804111] PGD 0
[0.804111] Oops:  [#1] SMP
[0.804111] Modules linked in:
[0.804111] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: GW
4.7.0-1.tos2_5 #1
[0.804111] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.8.2-20150714_191134- 04/01/2014
[0.804111] Workqueue: events_unbound async_run_entry_fn
[0.804111] task: 88003e214100 ti: 88003e264000 task.ti:
88003e264000
[0.804111] RIP: 0010:[]  []
kernfs_find_ns+0x17/0xf0
[0.804111] RSP: 0018:88003e267868  EFLAGS: 00010282
[0.804111] RAX: 88003e214100 RBX:  RCX:
88003e264008
[0.804111] RDX:  RSI: 8166bb80 RDI:

[0.804111] RBP: 88003e267898 R08:  R09:
8166bb80
[0.804111] R10: 000c6000 R11: 0001 R12:
8166bb80
[0.804111] R13:  R14: 8173048a R15:
88003b17b1a0
[0.804111] FS:  () GS:88003fc0()
knlGS:
[0.804111] CS:  0010 DS:  ES:  CR0: 80050033
[0.804111] CR2: 0068 CR3: 01806000 CR4:
000406f0
[0.804111] Stack:
[0.804111]  88003e267898  8801

[0.804111]  8166bb80  88003e2678c8
811e1e77
[0.804111]  0096 81873d40 88003b152828
0005
[0.804111] Call Trace:
[0.804111]  [] kernfs_find_and_get_ns+0x37/0x60
[0.804111]  [] sysfs_unmerge_group+0x18/0x60
[0.804111]  [] dpm_sysfs_remove+0x27/0x60



Thanks for any suggestion.
-Tapas
Ps : I could not send any attachment, is it possible to send attachment to
this mailing list ?






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.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Jason Cooper]

Hi Ted,

On Tue, Aug 09, 2016 at 07:56:22AM -0400, Theodore Ts'o wrote:
> On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> > Agree with Jason's point, also understand Stephan's concern.  The
> > date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> > 1000', the average speed is .294Kibits/s. I will sent the patch
> > to disable ath9k RNG by default.
> 
> If the ATH9K is generating some random amount of data, but you don't
> know how random, and you're gathering it opportunistically --- for
> example, suppose a wireless driver gets the radio's signal strength
> through the normal course of its operation, and while there might not
> be that much randomness for someone who can observe the exact details
> of how the phone is positioned in the room --- but for which the
> analyst sitting in Fort Meade won't know whether or not the phone is
> on the desk, or in a knapsack under the table, the right interface to
> use is:
> 
>void add_device_randomness(const void *buf, unsigned int size);
>   
> This won't increase the entropy count, but if you have the bit of
> potential randomness "for free", you might as well contribute it to
> the entropy pool.  If it turns out that the chip was manufactured in
> China, and the MSS has backdoored it out the wazoo, it won't do any
> harm --- where as using the hwrng framework would be disastrous.

Ok, I get that.  However, we have Documentation/hw_random.txt saying:

  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.

Which I would read as "Don't assume 1 bit read from /dev/hwrng equals 1
bit of entropy."  Which runs counter to Stephan's reading of the rngd
code.

And then we have drivers like timeriomem-rng.c that appear to be
spitting out the raw 32bit register value of $SOC's timer.

Thankfully, most hw_random drivers don't set the quality.  So unless the
user sets the default_quality param, it's zero.

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?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: testmgr.h

[Stephan Mueller]

Am Dienstag, 9. August 2016, 08:21:43 CEST schrieb Gary R Hook:

Hi Gary,

> Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
> Two cases:
> 
> 1) Tests from the NIST document(s) on various ciphers and hashes wherein
> we add to an existing set of tests? For example, 3DES ECB mode, or AES
> GCM? I suppose this question is really about, "how much is enough?"
> 
> 2) Adding testing for a mode that has not heretofore been included? For
> example, 3DES CFB mode? Pretty sure the answer here is "yes".
> 
> Over-arching concern: do we want to include official NIST test cases, or
> eschew them?
> 
> There was no obvious reference to this (by way of grepping for testmgr)
> in any of the existing Documentation. That I could find. If I missed
> something, please excuse me.

It is always helpful to use test vectors that are created by some third 
parties. These are NIST test vectors or test vectors in RFCs. In some cases, 
vectors were created using OpenSSL.

Regarding the question how much: I can only answer to the FIPS 140-2 
requirements: all tests that need to be there for FIPS 140-2 are there for 
those with fips_allowed=1.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

testmgr.h

[Gary R Hook]

Q: Is there a policy (de facto or otherwise) on adding tests to testmgr.h?
Two cases:

1) Tests from the NIST document(s) on various ciphers and hashes wherein
we add to an existing set of tests? For example, 3DES ECB mode, or AES
GCM? I suppose this question is really about, "how much is enough?"

2) Adding testing for a mode that has not heretofore been included? For
example, 3DES CFB mode? Pretty sure the answer here is "yes".

Over-arching concern: do we want to include official NIST test cases, or
eschew them?

There was no obvious reference to this (by way of grepping for testmgr)
in any of the existing Documentation. That I could find. If I missed
something, please excuse me.

Thanks,
Gary
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 1/4] crypto: add template handling for RNGs

[Stephan Mueller]

This patch adds the ability to register templates for RNGs. RNGs are
"meta" mechanisms using raw cipher primitives. Thus, RNGs can now be
implemented as templates to allow the complete flexibility the kernel
crypto API provides.

Signed-off-by: Stephan Mueller 
---
 crypto/rng.c  | 44 +++
 include/crypto/internal/rng.h | 26 +
 2 files changed, 70 insertions(+)

diff --git a/crypto/rng.c b/crypto/rng.c
index b81cffb..a4ee894 100644
--- a/crypto/rng.c
+++ b/crypto/rng.c
@@ -63,6 +63,25 @@ static int crypto_rng_init_tfm(struct crypto_tfm *tfm)
return 0;
 }
 
+static inline struct rng_alg *__crypto_rng_alg(struct crypto_alg *alg)
+{
+   return container_of(alg, struct rng_alg, base);
+}
+
+static inline struct rng_instance *rng_instance(
+   struct crypto_instance *inst)
+{
+   return container_of(__crypto_rng_alg(>alg),
+   struct rng_instance, alg);
+}
+
+static void crypto_rng_free_instance(struct crypto_instance *inst)
+{
+   struct rng_instance *rng = rng_instance(inst);
+
+   rng->free(rng);
+}
+
 static unsigned int seedsize(struct crypto_alg *alg)
 {
struct rng_alg *ralg = container_of(alg, struct rng_alg, base);
@@ -105,6 +124,7 @@ static void crypto_rng_show(struct seq_file *m, struct 
crypto_alg *alg)
 static const struct crypto_type crypto_rng_type = {
.extsize = crypto_alg_extsize,
.init_tfm = crypto_rng_init_tfm,
+   .free = crypto_rng_free_instance,
 #ifdef CONFIG_PROC_FS
.show = crypto_rng_show,
 #endif
@@ -232,5 +252,29 @@ void crypto_unregister_rngs(struct rng_alg *algs, int 
count)
 }
 EXPORT_SYMBOL_GPL(crypto_unregister_rngs);
 
+static int rng_prepare_alg(struct rng_alg *alg)
+{
+   struct crypto_alg *base = >base;
+
+   base->cra_type = _rng_type;
+   base->cra_flags &= ~CRYPTO_ALG_TYPE_MASK;
+   base->cra_flags |= CRYPTO_ALG_TYPE_RNG;
+
+   return 0;
+}
+
+int rng_register_instance(struct crypto_template *tmpl,
+ struct rng_instance *inst)
+{
+   int err;
+
+   err = rng_prepare_alg(>alg);
+   if (err)
+   return err;
+
+   return crypto_register_instance(tmpl, rng_crypto_instance(inst));
+}
+EXPORT_SYMBOL_GPL(rng_register_instance);
+
 MODULE_LICENSE("GPL");
 MODULE_DESCRIPTION("Random Number Generator");
diff --git a/include/crypto/internal/rng.h b/include/crypto/internal/rng.h
index a52ef34..aeaf58f 100644
--- a/include/crypto/internal/rng.h
+++ b/include/crypto/internal/rng.h
@@ -42,4 +42,30 @@ static inline void crypto_rng_set_entropy(struct crypto_rng 
*tfm,
crypto_rng_alg(tfm)->set_ent(tfm, data, len);
 }
 
+struct rng_instance {
+   void (*free)(struct rng_instance *inst);
+   struct rng_alg alg;
+};
+
+static inline struct rng_instance *rng_alloc_instance(
+   const char *name, struct crypto_alg *alg)
+{
+   return crypto_alloc_instance2(name, alg,
+ sizeof(struct rng_instance) - sizeof(*alg));
+}
+
+static inline struct crypto_instance *rng_crypto_instance(
+   struct rng_instance *inst)
+{
+   return container_of(>alg.base, struct crypto_instance, alg);
+}
+
+static inline void *rng_instance_ctx(struct rng_instance *inst)
+{
+   return crypto_instance_ctx(rng_crypto_instance(inst));
+}
+
+int rng_register_instance(struct crypto_template *tmpl,
+ struct rng_instance *inst);
+
 #endif
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 2/4] crypto: kdf - add known answer tests

[Stephan Mueller]

Add known answer tests to the testmgr for the KDF (SP800-108) cipher.

Signed-off-by: Stephan Mueller 
---
 crypto/testmgr.c | 226 +++
 crypto/testmgr.h | 110 +++
 2 files changed, 336 insertions(+)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index c2a8bd3..8ac1a2d 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -116,6 +116,11 @@ struct drbg_test_suite {
unsigned int count;
 };
 
+struct kdf_test_suite {
+   struct kdf_testvec *vecs;
+   unsigned int count;
+};
+
 struct akcipher_test_suite {
struct akcipher_testvec *vecs;
unsigned int count;
@@ -139,6 +144,7 @@ struct alg_test_desc {
struct hash_test_suite hash;
struct cprng_test_suite cprng;
struct drbg_test_suite drbg;
+   struct kdf_test_suite kdf;
struct akcipher_test_suite akcipher;
struct kpp_test_suite kpp;
} suite;
@@ -1758,6 +1764,64 @@ outbuf:
return ret;
 }
 
+static int kdf_cavs_test(struct kdf_testvec *test,
+const char *driver, u32 type, u32 mask)
+{
+   int ret = -EAGAIN;
+   struct crypto_rng *drng;
+   unsigned char *buf = kzalloc(test->expectedlen, GFP_KERNEL);
+
+   if (!buf)
+   return -ENOMEM;
+
+   drng = crypto_alloc_rng(driver, type | CRYPTO_ALG_INTERNAL, mask);
+   if (IS_ERR(drng)) {
+   printk(KERN_ERR "alg: kdf: could not allocate cipher handle "
+  "for %s\n", driver);
+   kzfree(buf);
+   return -ENOMEM;
+   }
+
+   ret = crypto_rng_reset(drng, test->K1, test->K1len);
+   if (ret) {
+   printk(KERN_ERR "alg: kdf: could not set key derivation key\n");
+   goto err;
+   }
+
+   ret = crypto_rng_generate(drng, test->context, test->contextlen,
+ buf, test->expectedlen);
+   if (ret) {
+   printk(KERN_ERR "alg: kdf: could not obtain key data\n");
+   goto err;
+   }
+
+   ret = memcmp(test->expected, buf, test->expectedlen);
+
+err:
+   crypto_free_rng(drng);
+   kzfree(buf);
+   return ret;
+}
+
+static int alg_test_kdf(const struct alg_test_desc *desc, const char *driver,
+   u32 type, u32 mask)
+{
+   int err = 0;
+   unsigned int i = 0;
+   struct kdf_testvec *template = desc->suite.kdf.vecs;
+   unsigned int tcount = desc->suite.kdf.count;
+
+   for (i = 0; i < tcount; i++) {
+   err = kdf_cavs_test([i], driver, type, mask);
+   if (err) {
+   printk(KERN_ERR "alg: kdf: Test %d failed for %s\n",
+  i, driver);
+   err = -EINVAL;
+   break;
+   }
+   }
+   return err;
+}
 
 static int alg_test_drbg(const struct alg_test_desc *desc, const char *driver,
 u32 type, u32 mask)
@@ -3467,6 +3531,168 @@ static const struct alg_test_desc alg_test_descs[] = {
.fips_allowed = 1,
.test = alg_test_null,
}, {
+   .alg = "kdf_ctr(cmac(aes))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(cmac(des3_ede))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(hmac(sha1))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(hmac(sha224))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(hmac(sha256))",
+   .test = alg_test_kdf,
+   .fips_allowed = 1,
+   .suite = {
+   .kdf = {
+   .vecs = kdf_ctr_hmac_sha256_tv_template,
+   .count = 
ARRAY_SIZE(kdf_ctr_hmac_sha256_tv_template)
+   }
+   }
+   }, {
+   .alg = "kdf_ctr(hmac(sha384))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(hmac(sha512))",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(sha1)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(sha224)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(sha256)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = "kdf_ctr(sha384)",
+   .test = alg_test_null,
+   .fips_allowed = 1,
+   }, {
+   .alg = 

[PATCH v5 3/4] crypto: kdf - SP800-108 Key Derivation Function

[Stephan Mueller]

The SP800-108 compliant Key Derivation Function is implemented as a
random number generator considering that it behaves like a deterministic
RNG.

All three KDF types specified in SP800-108 are implemented.

The code comments provide details about how to invoke the different KDF
types.

Signed-off-by: Stephan Mueller 
---
 crypto/kdf.c | 508 +++
 1 file changed, 508 insertions(+)
 create mode 100644 crypto/kdf.c

diff --git a/crypto/kdf.c b/crypto/kdf.c
new file mode 100644
index 000..6f9f082
--- /dev/null
+++ b/crypto/kdf.c
@@ -0,0 +1,508 @@
+/*
+ * Copyright (C) 2016, Stephan Mueller 
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ * 1. Redistributions of source code must retain the above copyright
+ *notice, and the entire permission notice in its entirety,
+ *including the disclaimer of warranties.
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *notice, this list of conditions and the following disclaimer in the
+ *documentation and/or other materials provided with the distribution.
+ * 3. The name of the author may not be used to endorse or promote
+ *products derived from this software without specific prior
+ *written permission.
+ *
+ * ALTERNATIVELY, this product may be distributed under the terms of
+ * the GNU General Public License, in which case the provisions of the GPL2
+ * are required INSTEAD OF the above restrictions.  (This clause is
+ * necessary due to a potential bad interaction between the GPL and
+ * the restrictions contained in a BSD-style copyright.)
+ *
+ * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
+ * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
+ * WHICH ARE HEREBY DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
+ * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
+ * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
+ * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
+ * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
+ * DAMAGE.
+ */
+
+/*
+ * For performing a KDF operation, the following input is required
+ * from the caller:
+ *
+ * * Keying material to be used to derive the new keys from
+ *   (denoted as Ko in SP800-108)
+ * * Label -- a free form binary string
+ * * Context -- a free form binary string
+ *
+ * The KDF is implemented as a random number generator.
+ *
+ * The Ko keying material is to be provided with the initialization of the KDF
+ * "random number generator", i.e. with the crypto_rng_reset function.
+ *
+ * The Label and Context concatenated string is provided when obtaining random
+ * numbers, i.e. with the crypto_rng_generate function. The caller must format
+ * the free-form Label || Context input as deemed necessary for the given
+ * purpose. Note, SP800-108 mandates that the Label and Context are separated
+ * by a 0x00 byte, i.e. the caller shall provide the input as
+ * Label || 0x00 || Context when trying to be compliant to SP800-108. For
+ * the feedback KDF, an IV is required as documented below.
+ *
+ * Example without proper error handling:
+ * char *keying_material = "\x00\x11\x22\x33\x44\x55\x66\x77";
+ * char *label_context = "\xde\xad\xbe\xef\x00\xde\xad\xbe\xef";
+ * kdf = crypto_alloc_rng(name, 0, 0);
+ * crypto_rng_reset(kdf, keying_material, 8);
+ * crypto_rng_generate(kdf, label_context, 9, outbuf, outbuflen);
+ *
+ * NOTE: In-place cipher operations are not supported.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct crypto_kdf_ctx {
+   struct shash_desc shash;
+   char ctx[];
+};
+
+/* convert 32 bit integer into its string representation */
+static inline void crypto_kw_cpu_to_be32(u32 val, u8 *buf)
+{
+   __be32 *a = (__be32 *)buf;
+
+   *a = cpu_to_be32(val);
+}
+
+/*
+ * Implementation of the KDF in double pipeline iteration mode according with
+ * counter to SP800-108 section 5.3.
+ *
+ * The caller must provide Label || 0x00 || Context in src. This src pointer
+ * may also be NULL if the caller wishes not to provide anything.
+ */
+static int crypto_kdf_dpi_random(struct crypto_rng *rng,
+const u8 *src, unsigned int slen,
+u8 *dst, unsigned int dlen)
+{
+   struct crypto_kdf_ctx *ctx = crypto_tfm_ctx(crypto_rng_tfm(rng));
+   struct shash_desc *desc = >shash;
+   unsigned int h = crypto_shash_digestsize(desc->tfm);
+   unsigned int alignmask 

[PATCH v5 0/4] crypto: Key Derivation Function (SP800-108)

[Stephan Mueller]

Hi,

this patch set implements all three key derivation functions defined in
SP800-108.

The implementation is provided as a template for random number generators,
since a KDF can be considered a form of deterministic RNG where the key
material is used as a seed.

With the KDF implemented as a template, all types of keyed and
non-keyed hashes can be utilized, including HMAC and CMAC. The testmgr
tests are derived from publicly available test vectors from NIST.

The KDF are all tested with a complete round of CAVS testing on 32 and 64 bit.

The patch set introduces an extension to the kernel crypto API in the first
patch by adding a template handling for random number generators based on the
same logic as for keyed hashes.

Changes v5:
* move rng_instance and __crypto_rng_alg into rng.c

Changes v4:
* removal of the check that src and dst buffers are not the same from the KDF
  implementations as requested by Herbert
* implement and use new free API in the RNG instance handling as requested
  by Herbert
* move the instance handling code from include/crypto/rng.h to
  include/crypto/internal/rng.h

Changes v3:
* port testmgr patch to current cryptodev-2.6 tree
* add non-keyed KDF references to testmgr.c

Changes v2:
* port to 4.7-rc1

Stephan Mueller (4):
  crypto: add template handling for RNGs
  crypto: kdf - add known answer tests
  crypto: kdf - SP800-108 Key Derivation Function
  crypto: kdf - enable compilation

 crypto/Kconfig|   7 +
 crypto/Makefile   |   1 +
 crypto/kdf.c  | 508 ++
 crypto/rng.c  |  44 
 crypto/testmgr.c  | 226 +++
 crypto/testmgr.h  | 110 +
 include/crypto/internal/rng.h |  26 +++
 7 files changed, 922 insertions(+)
 create mode 100644 crypto/kdf.c

-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v5 4/4] crypto: kdf - enable compilation

[Stephan Mueller]

Include KDF into Kconfig and Makefile for compilation.

Signed-off-by: Stephan Mueller 
---
 crypto/Kconfig  | 7 +++
 crypto/Makefile | 1 +
 2 files changed, 8 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 84d7148..16f3221 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -372,6 +372,13 @@ config CRYPTO_KEYWRAP
  Support for key wrapping (NIST SP800-38F / RFC3394) without
  padding.
 
+config CRYPTO_KDF
+   tristate "Key Derivation Function (SP800-108)"
+   select CRYPTO_RNG
+   help
+ Support for KDF compliant to SP800-108. All three types of
+ KDF specified in SP800-108 are implemented.
+
 comment "Hash modes"
 
 config CRYPTO_CMAC
diff --git a/crypto/Makefile b/crypto/Makefile
index 99cc64a..9022280 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -80,6 +80,7 @@ obj-$(CONFIG_CRYPTO_LRW) += lrw.o
 obj-$(CONFIG_CRYPTO_XTS) += xts.o
 obj-$(CONFIG_CRYPTO_CTR) += ctr.o
 obj-$(CONFIG_CRYPTO_KEYWRAP) += keywrap.o
+obj-$(CONFIG_CRYPTO_KDF) += kdf.o
 obj-$(CONFIG_CRYPTO_GCM) += gcm.o
 obj-$(CONFIG_CRYPTO_CCM) += ccm.o
 obj-$(CONFIG_CRYPTO_CHACHA20POLY1305) += chacha20poly1305.o
-- 
2.7.4


--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Theodore Ts'o]

On Tue, Aug 09, 2016 at 06:30:03AM +, Pan, Miaoqing wrote:
> Agree with Jason's point, also understand Stephan's concern.  The
> date rate can be roughly estimated by 'cat /dev/random |rngtest -c
> 1000', the average speed is .294Kibits/s. I will sent the patch
> to disable ath9k RNG by default.

If the ATH9K is generating some random amount of data, but you don't
know how random, and you're gathering it opportunistically --- for
example, suppose a wireless driver gets the radio's signal strength
through the normal course of its operation, and while there might not
be that much randomness for someone who can observe the exact details
of how the phone is positioned in the room --- but for which the
analyst sitting in Fort Meade won't know whether or not the phone is
on the desk, or in a knapsack under the table, the right interface to
use is:

   void add_device_randomness(const void *buf, unsigned int size);

This won't increase the entropy count, but if you have the bit of
potential randomness "for free", you might as well contribute it to
the entropy pool.  If it turns out that the chip was manufactured in
China, and the MSS has backdoored it out the wazoo, it won't do any
harm --- where as using the hwrng framework would be disastrous.

Cheerfs,

- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] Various fixes for the cesa driver

[Herbert Xu]

Romain Perier  wrote:
> This patches series contains various fixes for ahash requests, dma
> operations and an important fixe in the core of the driver (cesa.c). It
> also includes some code cleanups.

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: crypto: crc32c-vpmsum - Convert to CPU feature based module autoloading

[Michael Ellerman]

On Thu, 2016-04-08 at 06:38:15 UTC, Anton Blanchard wrote:
> From: Anton Blanchard 
> 
> This patch utilises the GENERIC_CPU_AUTOPROBE infrastructure
> to automatically load the crc32c-vpmsum module if the CPU supports
> it.
> 
> Signed-off-by: Anton Blanchard 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/d2cf5be07ff7c7cde8bef8551a

cheers
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: caam - avoid kernel warnings on probe failure

[Herbert Xu]

On Tue, Aug 09, 2016 at 08:30:10AM +0100, Russell King wrote:
> While debugging setkey issues, the following warnings were found while
> trying to reinsert the caam module.  Fix this by avoiding the duplicated
> cleanup in the probe path after caam_remove(), which has already cleaned
> up the resources.

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/11] Further iMX CAAM updates

[Herbert Xu]

On Mon, Aug 08, 2016 at 06:04:01PM +0100, Russell King - ARM Linux wrote:
> This is a re-post (with hopefully bugs fixed from December's review).
> Untested, because AF_ALG appears to be broken in 4.8-rc1.  Maybe
> someone can provide some hints how to test using tcrypt please?
> 
> Here are further imx-caam updates that I've had since before the
> previous merge window.  Please review and (I guess) if Freescale
> folk can provide acks etc that would be nice.  Thanks.
> 
>  drivers/crypto/caam/caamhash.c | 540 
> ++---
>  drivers/crypto/caam/intern.h   |   1 -
>  drivers/crypto/caam/jr.c   |  25 +-
>  3 files changed, 305 insertions(+), 261 deletions(-)

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/7] crypto: img-hash - fixes and interface changes

[Herbert Xu]

On Fri, Aug 05, 2016 at 02:00:13PM +0100, Will Thomas wrote:
> Hi Herbert,
> 
> This patchset includes small stability fixes, power management
> and import/export interface functions for the img-hash driver.
> 
> Changes as discussed for [1/7], [2/7] and [5/7].
> 
> 
> Govindraj Raja (1):
>   crypto: img-hash - Add suspend resume hooks for img hash
> 
> James Hartley (2):
>   crypto: img-hash - Add support for export and import
>   crypto: img-hash - log a successful probe
> 
> Will Thomas (4):
>   crypto: img-hash - Fix null pointer exception
>   crypto: img-hash - Fix hash request context
>   crypto: img-hash - Reconfigure DMA Burst length
>   crypto: img-hash - Fix set_reqsize call

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto/testmgr.c: fix !x==y confusion

[Herbert Xu]

On Fri, Jul 29, 2016 at 04:32:09PM +0800, yanjiang@windriver.com wrote:
> From: Yanjiang Jin 
> 
> "if (!ret == template[i].fail)" is confusing to compilers (gcc5):
> 
> crypto/testmgr.c: In function '__test_aead':
> crypto/testmgr.c:531:12: warning: logical not is only applied to the
> left hand side of comparison [-Wlogical-not-parentheses]
>if (!ret == template[i].fail) {
> ^
> 
> Let there be 'if (template[i].fail == !ret) '.
> 
> Signed-off-by: Yanjiang Jin 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 00/10] Enablement of a v5 CCP

[Herbert Xu]

On Tue, Jul 26, 2016 at 07:09:11PM -0500, Gary R Hook wrote:
> The following series updates the CCP driver to support
> both current and new cryptographic coprocessor models.
> Refactor code to further separate device-specific code
> from driver logic, then add equivalent support for the
> new device version.
> 
> ---
> 
> Gary R Hook (10):
>   crypto: ccp - Abstract PCI info for the CCP
>   crypto: ccp - Shorten the fields of the action structure
>   crypto: ccp - Refactoring: symbol cleanup
>   crypto: ccp - Refactor the storage block allocation code
>   crypto: ccp - Refactor code supporting the CCP's RNG
>   crypto: ccp - Refactor code to enable checks for queue space.
>   crypto: ccp - Let a v5 CCP provide the same function as v3
>   crypto: ccp - Add support for the RNG in a version 5 CCP
>   crypto: ccp - Enable DMA service on a v5 CCP
>   crypto: ccp - Enable use of the additional CCP

All applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] crypto: ccp - Fix non-conforming comment style

[Herbert Xu]

On Tue, Jul 26, 2016 at 06:09:46PM -0500, Gary R Hook wrote:
> Adhere to the cryptodev comment convention.
> 
> Signed-off-by: Gary R Hook 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] Fix a resource release omission in error handling code

[Herbert Xu]

On Fri, Jul 22, 2016 at 03:32:40PM +0200, Quentin Lambert wrote:
> The first patch is a style fix, the second add calls to npe_release.
> The reason for me thinking that they are necessary is that every other 
> branches
> leading to an error return are calling this function.

Both patches applied.  BTW, your patches came in the wrong order.
Please send them in the correct order next time.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] crypto: powerpc - CRYPT_CRC32C_VPMSUM should depend on ALTIVEC

[Herbert Xu]

On Tue, Aug 09, 2016 at 08:46:15AM +1000, Michael Ellerman wrote:
> The optimised crc32c implementation depends on VMX (aka. Altivec)
> instructions, so the kernel must be built with Altivec support in order
> for the crc32c code to build.
> 
> Fixes: 6dd7a82cc54e ("crypto: powerpc - Add POWER8 optimised crc32c")
> Acked-by: Anton Blanchard 
> Signed-off-by: Michael Ellerman 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AF_ALG broken?

[Herbert Xu]

On Tue, Aug 09, 2016 at 08:27:17AM +0100, Russell King - ARM Linux wrote:
>
> From: Russell King 
> Subject: [PATCH] crypto: caam - fix non-hmac hashes
> 
> Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
> accept(2)"), the AF_ALG interface requires userspace to provide a key
> to any algorithm that has a setkey method.  However, the non-HMAC
> algorithms are not keyed, so setting a key is unnecessary.
> 
> Fix this by removing the setkey method from the non-keyed hash
> algorithms.
> 
> Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
> Cc: 
> Signed-off-by: Russell King 

Patch applied.  Thanks.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Henrique de Moraes Holschuh]

On Tue, 09 Aug 2016, Stephan Mueller wrote:
> RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools 
> then 
> broken (at least in those large distros)?

Might I humbly suggest that the kernel start providing some metatada
about the quality of the random source that userspace can consume?
Preferably by a new ioctl, so that it will fit naturally if we ever
extend /dev/hwrng to support more than one source?

That would allow for auto tunning to be implemented in userspace...

-- 
  Henrique Holschuh
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv3 03/11] crypto: omap-sham: implement context export/import APIs

[Herbert Xu]

On Thu, Aug 04, 2016 at 01:28:38PM +0300, Tero Kristo wrote:
> Context export/import are now required for ahash algorithms due to
> required support in algif_hash. Implement these for OMAP SHA driver,
> saving and restoring the internal state of the driver.
> 
> Signed-off-by: Tero Kristo 
> ---
>  drivers/crypto/omap-sham.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/omap-sham.c
> index 6e53944..aa71e61 100644
> --- a/drivers/crypto/omap-sham.c
> +++ b/drivers/crypto/omap-sham.c
> @@ -1379,6 +1379,27 @@ exit_unlock:
>   return ret;
>  }
>  
> +static int omap_sham_export(struct ahash_request *req, void *out)
> +{
> + struct omap_sham_reqctx *rctx = ahash_request_ctx(req);
> +
> + while (omap_sham_flush(req) == -EINPROGRESS)
> + msleep(10);

Do we really need this? You must not call export until the previous
operation has completed.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 17:56:57 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> > Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
> > 
> > Hi Herbert,
> > 
> > > You're supposed to tweak the quality of the input.  In any case,
> > 
> > How is that tweak supposed to happen? The rngd does not allow changing the
> > amount of read data relative to the assumed entropy.
> 
> Hmm, I guess it depends on your distro.  Some do.
> 
> Cheers,

RHEL 7 and Fedora do not adjust it. So, shall we consider those rng-tools then 
broken (at least in those large distros)?

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v4 1/4] crypto: add template handling for RNGs

[Herbert Xu]

Stephan Mueller  wrote:
> +
> +static inline struct rng_alg *__crypto_rng_alg(struct crypto_alg *alg)
> +{
> +   return container_of(alg, struct rng_alg, base);
> +}
> +
> +static inline struct rng_instance *rng_instance(
> +   struct crypto_instance *inst)
> +{
> +   return container_of(__crypto_rng_alg(>alg),
> +   struct rng_instance, alg);
> +}

Please move these functions into rng.c.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Herbert Xu]

On Tue, Aug 09, 2016 at 11:56:08AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:
> 
> Hi Herbert,
> > 
> > You're supposed to tweak the quality of the input.  In any case,
> 
> How is that tweak supposed to happen? The rngd does not allow changing the 
> amount of read data relative to the assumed entropy.

Hmm, I guess it depends on your distro.  Some do.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 17:46:56 CEST schrieb Herbert Xu:

Hi Herbert,
> 
> You're supposed to tweak the quality of the input.  In any case,

How is that tweak supposed to happen? The rngd does not allow changing the 
amount of read data relative to the assumed entropy.

> this is not affected by whether we whiten the result.

I understand that.

Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices

[Herbert Xu]

On Mon, Jul 25, 2016 at 01:07:35PM -0700, Keith Packard wrote:
> Instead of having only one hwrng feeding /dev/random at a time, maintain
> a list of devices and cycle between them when filling the entropy pool.
> 
> Signed-off-by: Keith Packard 

So you're cycling RNGs even for user-space reads? That could be
problematic because not all hardware RNGs carry the maximum amount
of entropy.  It would be rather annoying to be cycling between
RNGs of different qualities.

Perhaps only cycle for the kernel hwrngd?

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/7] Various fixes for the cesa driver

[Thomas Petazzoni]

Hello,

Is it normal that Herbert, as the crypto maintainer, is not Cc'ed on
those patches?

On Tue,  9 Aug 2016 11:03:13 +0200, Romain Perier wrote:
> This patches series contains various fixes for ahash requests, dma
> operations and an important fixe in the core of the driver (cesa.c). It
> also includes some code cleanups.
> 
> Romain Perier (3):
>   crypto: marvell - Update transformation context for each dequeued req
>   crypto: marvell - Don't overwrite default creq->state during
> initialization

I think those two patches should have come first in the series, to make
it clear that they are the two fixes that are important to merge for
the 4.8 release cycle.

>   crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req
> 
> Thomas Petazzoni (4):
>   crypto: marvell: be explicit about destination in mv_cesa_dma_add_op()
>   crypto: marvell: remove unused parameter in
> mv_cesa_ahash_dma_add_cache()
>   crypto: marvell: turn mv_cesa_ahash_init() into a function returning
> void
>   crypto: marvell: make mv_cesa_ahash_cache_req() return bool

Those 5 other patches (the four from me and the last one from you) are
more cleanups/improvements, which can wait the 4.9 release cycle.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Herbert Xu]

On Tue, Aug 09, 2016 at 11:37:39AM +0200, Stephan Mueller wrote:
> Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:
> 
> Hi Herbert,
> 
> > On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > > But shouldn't the default of the rngd then be adjusted a bit?
> > 
> > Please elaborate.
> 
> in rngd_linux.c:random_add_entropy(void *buf, size_t size):
> 
> entropy.ent_count = size * 8;
> entropy.size = size;
> memcpy(entropy.data, buf, size);
> 
> if (ioctl(random_fd, RNDADDENTROPY, ) != 0) {
> 
> ...
> 
> 
> in rngd.c:do_loop():
> 
> retval = iter->xread(buf, sizeof buf, iter);
> ...
> rc = update_kernel_random(random_step,
>  buf, iter->fipsctx);
> 
> where update_kernel_random simply invokes random_add_entropy in chunks.
> 
> Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
> random with an entropy estimate that is equal to the read bytes.
> 
> With less than perfect noise sources, entropy.ent_count should be much 
> smaller.

You're supposed to tweak the quality of the input.  In any case,
this is not affected by whether we whiten the result.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AF_ALG zero-size hash fails

[Herbert Xu]

On Tue, Aug 09, 2016 at 10:18:34AM +0100, Russell King - ARM Linux wrote:
> Hi,
> 
> While testing AF_ALG with openssl af-alg-rr, I've found that:
> 
> OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1  
> fails with a zero hash result:
> 
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> close(3)= 0
> socket(PF_ALG, SOCK_SEQPACKET, 0)   = 3
> bind(3, {sa_family=AF_ALG, sa_data="hash\0\0\0\0\0\0\0\0\0\0"}, 88) = 0
> accept(3, 0, NULL)  = 4
> fstat64(0, {st_mode=S_IFCHR|0666, st_rdev=makedev(1, 3), ...}) = 0
> ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, 
> 0xbed50d5c) = -1 ENOTTY (Inappropriate ioctl for device)
> mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
> 0xb6fe4000
> read(0, "", 8192)   = 0
> read(4, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", 20) = 20
> close(4)= 0
> close(3)= 0
> 
> tested with the Freescale CAAM driver with SHA1 and MD5 hashes, and
> the ARM SHA1 shash implementation.  Should there at least be a single
> write to the socket (of zero size) in this case, or should the kernel
> return the correct hash on the first read without a preceding
> write/send?

It's an oversight in the algif_hash code.  I'll get it fixed.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 17:17:55 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> > But shouldn't the default of the rngd then be adjusted a bit?
> 
> Please elaborate.

in rngd_linux.c:random_add_entropy(void *buf, size_t size):

entropy.ent_count = size * 8;
entropy.size = size;
memcpy(entropy.data, buf, size);

if (ioctl(random_fd, RNDADDENTROPY, ) != 0) {

...


in rngd.c:do_loop():

retval = iter->xread(buf, sizeof buf, iter);
...
rc = update_kernel_random(random_step,
 buf, iter->fipsctx);

where update_kernel_random simply invokes random_add_entropy in chunks.

Hence, the rngd reads some bytes from /dev/hwrand and injects it into /dev/
random with an entropy estimate that is equal to the read bytes.

With less than perfect noise sources, entropy.ent_count should be much 
smaller.
> 
> Thanks,



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Herbert Xu]

On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
> 
> But shouldn't the default of the rngd then be adjusted a bit?

Please elaborate.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

AF_ALG zero-size hash fails

[Russell King - ARM Linux]

Hi,

While testing AF_ALG with openssl af-alg-rr, I've found that:

OPENSSL_CONF=/shared/crypto/openssl-imx.cnf openssl dgst -sha1 http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 5/7] crypto: marvell - Update transformation context for each dequeued req

[Romain Perier]

So far, sub part of mv_cesa_int was responsible of dequeuing complete
requests, then call the 'cleanup' operation on these reqs and call the
crypto api callback 'complete'. The problem is that the transformation
context 'ctx' is retrieved only once before the while loop. Which means
that the wrong 'cleanup' operation might be called on the wrong type of
cesa requests, it can lead to memory corruptions with this message:

marvell-cesa f109.crypto: dma_pool_free cesa_padding, 5a5a5a5a/5a5a5a5a 
(bad dma)

This commit fixes the issue, by updating the transformation context for
each dequeued cesa request.

Fixes: commit 85030c5168f1 ("crypto: marvell - Add support for chai...")
Signed-off-by: Romain Perier 
---
 drivers/crypto/marvell/cesa.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/marvell/cesa.c b/drivers/crypto/marvell/cesa.c
index d64af86..37dadb2 100644
--- a/drivers/crypto/marvell/cesa.c
+++ b/drivers/crypto/marvell/cesa.c
@@ -166,6 +166,7 @@ static irqreturn_t mv_cesa_int(int irq, void *priv)
if (!req)
break;
 
+   ctx = crypto_tfm_ctx(req->tfm);
mv_cesa_complete_req(ctx, req, 0);
}
}
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 7/7] crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req

[Romain Perier]

Don't use 64 'as is', as max block size in mv_cesa_ahash_cache_req. Use
CESA_MAX_HASH_BLOCK_SIZE instead, this is better for readability.

Signed-off-by: Romain Perier 
---
 drivers/crypto/marvell/hash.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 44a8abe..9f28468 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -408,7 +408,7 @@ static bool mv_cesa_ahash_cache_req(struct ahash_request 
*req)
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
bool cached = false;
 
-   if (creq->cache_ptr + req->nbytes < 64 && !creq->last_req) {
+   if (creq->cache_ptr + req->nbytes < CESA_MAX_HASH_BLOCK_SIZE && 
!creq->last_req) {
cached = true;
 
if (!req->nbytes)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 4/7] crypto: marvell: make mv_cesa_ahash_cache_req() return bool

[Romain Perier]

From: Thomas Petazzoni 

The mv_cesa_ahash_cache_req() function always returns 0, which makes
its return value pretty much useless. However, in addition to
returning a useless value, it also returns a boolean in a variable
passed by reference to indicate if the request was already cached.

So, this commit changes mv_cesa_ahash_cache_req() to return this
boolean. It consequently simplifies the only call site of
mv_cesa_ahash_cache_req(), where the "ret" variable is no longer
needed.

Signed-off-by: Thomas Petazzoni 
---
 drivers/crypto/marvell/hash.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 7291664..cf8063d 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -403,15 +403,16 @@ static inline int mv_cesa_ahash_cra_init(struct 
crypto_tfm *tfm)
return 0;
 }
 
-static int mv_cesa_ahash_cache_req(struct ahash_request *req, bool *cached)
+static bool mv_cesa_ahash_cache_req(struct ahash_request *req)
 {
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
+   bool cached = false;
 
if (creq->cache_ptr + req->nbytes < 64 && !creq->last_req) {
-   *cached = true;
+   cached = true;
 
if (!req->nbytes)
-   return 0;
+   return cached;
 
sg_pcopy_to_buffer(req->src, creq->src_nents,
   creq->cache + creq->cache_ptr,
@@ -420,7 +421,7 @@ static int mv_cesa_ahash_cache_req(struct ahash_request 
*req, bool *cached)
creq->cache_ptr += req->nbytes;
}
 
-   return 0;
+   return cached;
 }
 
 static struct mv_cesa_op_ctx *
@@ -665,7 +666,6 @@ err:
 static int mv_cesa_ahash_req_init(struct ahash_request *req, bool *cached)
 {
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
-   int ret;
 
creq->src_nents = sg_nents_for_len(req->src, req->nbytes);
if (creq->src_nents < 0) {
@@ -673,17 +673,15 @@ static int mv_cesa_ahash_req_init(struct ahash_request 
*req, bool *cached)
return creq->src_nents;
}
 
-   ret = mv_cesa_ahash_cache_req(req, cached);
-   if (ret)
-   return ret;
+   *cached = mv_cesa_ahash_cache_req(req);
 
if (*cached)
return 0;
 
if (cesa_dev->caps->has_tdma)
-   ret = mv_cesa_ahash_dma_req_init(req);
-
-   return ret;
+   return mv_cesa_ahash_dma_req_init(req);
+   else
+   return 0;
 }
 
 static int mv_cesa_ahash_queue_req(struct ahash_request *req)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 6/7] crypto: marvell - Don't overwrite default creq->state during initialization

[Romain Perier]

Currently, in mv_cesa_{md5,sha1,sha256}_init creq->state is initialized
before the call to mv_cesa_ahash_init. This is wrong because this
function fills creq with zero by using memset, so its 'state' that
contains the default DIGEST is overwritten. This commit fixes the issue
by initializing creq->state just after the call to mv_cesa_ahash_init.

Fixes: commit b0ef51067cb4 ("crypto: marvell/cesa - initialize hash...")
Signed-off-by: Romain Perier 
---
 drivers/crypto/marvell/hash.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index cf8063d..44a8abe 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -800,13 +800,14 @@ static int mv_cesa_md5_init(struct ahash_request *req)
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_MD5);
+
+   mv_cesa_ahash_init(req, , true);
+
creq->state[0] = MD5_H0;
creq->state[1] = MD5_H1;
creq->state[2] = MD5_H2;
creq->state[3] = MD5_H3;
 
-   mv_cesa_ahash_init(req, , true);
-
return 0;
 }
 
@@ -868,14 +869,15 @@ static int mv_cesa_sha1_init(struct ahash_request *req)
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_SHA1);
+
+   mv_cesa_ahash_init(req, , false);
+
creq->state[0] = SHA1_H0;
creq->state[1] = SHA1_H1;
creq->state[2] = SHA1_H2;
creq->state[3] = SHA1_H3;
creq->state[4] = SHA1_H4;
 
-   mv_cesa_ahash_init(req, , false);
-
return 0;
 }
 
@@ -937,6 +939,9 @@ static int mv_cesa_sha256_init(struct ahash_request *req)
struct mv_cesa_op_ctx tmpl = { };
 
mv_cesa_set_op_cfg(, CESA_SA_DESC_CFG_MACM_SHA256);
+
+   mv_cesa_ahash_init(req, , false);
+
creq->state[0] = SHA256_H0;
creq->state[1] = SHA256_H1;
creq->state[2] = SHA256_H2;
@@ -946,8 +951,6 @@ static int mv_cesa_sha256_init(struct ahash_request *req)
creq->state[6] = SHA256_H6;
creq->state[7] = SHA256_H7;
 
-   mv_cesa_ahash_init(req, , false);
-
return 0;
 }
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 0/7] Various fixes for the cesa driver

[Romain Perier]

This patches series contains various fixes for ahash requests, dma
operations and an important fixe in the core of the driver (cesa.c). It
also includes some code cleanups.

Romain Perier (3):
  crypto: marvell - Update transformation context for each dequeued req
  crypto: marvell - Don't overwrite default creq->state during
initialization
  crypto: marvell - Don't hardcode block size in mv_cesa_ahash_cache_req

Thomas Petazzoni (4):
  crypto: marvell: be explicit about destination in mv_cesa_dma_add_op()
  crypto: marvell: remove unused parameter in
mv_cesa_ahash_dma_add_cache()
  crypto: marvell: turn mv_cesa_ahash_init() into a function returning
void
  crypto: marvell: make mv_cesa_ahash_cache_req() return bool

 drivers/crypto/marvell/cesa.c |  1 +
 drivers/crypto/marvell/hash.c | 44 +--
 drivers/crypto/marvell/tdma.c |  1 +
 3 files changed, 23 insertions(+), 23 deletions(-)

-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/7] crypto: marvell: remove unused parameter in mv_cesa_ahash_dma_add_cache()

[Romain Perier]

From: Thomas Petazzoni 

The dma_iter parameter of mv_cesa_ahash_dma_add_cache() is never used,
so get rid of it.

Signed-off-by: Thomas Petazzoni 
---
 drivers/crypto/marvell/hash.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 82e0f4e6..0d7f5f9 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -455,7 +455,6 @@ mv_cesa_dma_add_frag(struct mv_cesa_tdma_chain *chain,
 
 static int
 mv_cesa_ahash_dma_add_cache(struct mv_cesa_tdma_chain *chain,
-   struct mv_cesa_ahash_dma_iter *dma_iter,
struct mv_cesa_ahash_req *creq,
gfp_t flags)
 {
@@ -586,7 +585,7 @@ static int mv_cesa_ahash_dma_req_init(struct ahash_request 
*req)
 * Add the cache (left-over data from a previous block) first.
 * This will never overflow the SRAM size.
 */
-   ret = mv_cesa_ahash_dma_add_cache(>chain, , creq, flags);
+   ret = mv_cesa_ahash_dma_add_cache(>chain, creq, flags);
if (ret)
goto err_free_tdma;
 
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/7] crypto: marvell: turn mv_cesa_ahash_init() into a function returning void

[Romain Perier]

From: Thomas Petazzoni 

The mv_cesa_ahash_init() function always returns 0, and the return
value is anyway never checked. Turn it into a function returning void.

Signed-off-by: Thomas Petazzoni 
---
 drivers/crypto/marvell/hash.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/crypto/marvell/hash.c b/drivers/crypto/marvell/hash.c
index 0d7f5f9..7291664 100644
--- a/drivers/crypto/marvell/hash.c
+++ b/drivers/crypto/marvell/hash.c
@@ -374,7 +374,7 @@ static const struct mv_cesa_req_ops mv_cesa_ahash_req_ops = 
{
.complete = mv_cesa_ahash_complete,
 };
 
-static int mv_cesa_ahash_init(struct ahash_request *req,
+static void mv_cesa_ahash_init(struct ahash_request *req,
  struct mv_cesa_op_ctx *tmpl, bool algo_le)
 {
struct mv_cesa_ahash_req *creq = ahash_request_ctx(req);
@@ -390,8 +390,6 @@ static int mv_cesa_ahash_init(struct ahash_request *req,
creq->op_tmpl = *tmpl;
creq->len = 0;
creq->algo_le = algo_le;
-
-   return 0;
 }
 
 static inline int mv_cesa_ahash_cra_init(struct crypto_tfm *tfm)
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/7] crypto: marvell: be explicit about destination in mv_cesa_dma_add_op()

[Romain Perier]

From: Thomas Petazzoni 

The mv_cesa_dma_add_op() function builds a mv_cesa_tdma_desc structure
to copy the operation description to the SRAM, but doesn't explicitly
initialize the destination of the copy. It works fine because the
operatin description must be copied at the beginning of the SRAM, and
the mv_cesa_tdma_desc structure is initialized to zero when
allocated. However, it is somewhat confusing to not have a destination
defined.

Signed-off-by: Thomas Petazzoni 
---
 drivers/crypto/marvell/tdma.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/marvell/tdma.c b/drivers/crypto/marvell/tdma.c
index 86a065b..9fd7a5f 100644
--- a/drivers/crypto/marvell/tdma.c
+++ b/drivers/crypto/marvell/tdma.c
@@ -261,6 +261,7 @@ struct mv_cesa_op_ctx *mv_cesa_dma_add_op(struct 
mv_cesa_tdma_chain *chain,
tdma->op = op;
tdma->byte_cnt = cpu_to_le32(size | BIT(31));
tdma->src = cpu_to_le32(dma_handle);
+   tdma->dst = CESA_SA_CFG_SRAM_OFFSET;
tdma->flags = CESA_TDMA_DST_IN_SRAM | CESA_TDMA_OP;
 
return op;
-- 
2.8.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu:

Hi Herbert,

> On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> > Herbert, Matt, should such noise sources be added to the HW random
> > framework? The thing is that the in-kernel HW random to input_pool link
> > per default uses a more conservative entropy estimate than the user space
> > rngd. I would think that the in-kernel link would appropriate for that
> > rng. But the user space rngd tool with its default behavior is not really
> > suited here.
> 
> Yes hwrng would be the best fit, with a quality of zero to be safe.
> 
> Contrary to the quoted thread, there is no need to whiten the output
> /dev/hw_random.  It was always meant to go through some intermediate
> processing such as rngd before it is used.

But shouldn't the default of the rngd then be adjusted a bit?
> 
> Cheers,



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Herbert Xu]

On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> 
> Herbert, Matt, should such noise sources be added to the HW random framework? 
> The thing is that the in-kernel HW random to input_pool link per default uses 
> a more conservative entropy estimate than the user space rngd. I would think 
> that the in-kernel link would appropriate for that rng. But the user space 
> rngd tool with its default behavior is not really suited here.

Yes hwrng would be the best fit, with a quality of zero to be safe.

Contrary to the quoted thread, there is no need to whiten the output
/dev/hw_random.  It was always meant to go through some intermediate
processing such as rngd before it is used.

Cheers,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:

Hi Miaoqing, Herbert, Matt,

> Hi Stephan,
> 
> So your suggestion is to use HW Random framework ?   Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can refer to
> https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html
> for more information.

I see, it is the same RNG we talked about earlier. The issue is that the 
suggested rngd per default assumes one bit of entropy with every data bit. 
This is not given with this noise source. This is the basis of my reply last 
time.

Herbert, Matt, should such noise sources be added to the HW random framework? 
The thing is that the in-kernel HW random to input_pool link per default uses 
a more conservative entropy estimate than the user space rngd. I would think 
that the in-kernel link would appropriate for that rng. But the user space 
rngd tool with its default behavior is not really suited here.

Thanks
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] crypto: caam - avoid kernel warnings on probe failure

[Russell King]

While debugging setkey issues, the following warnings were found while
trying to reinsert the caam module.  Fix this by avoiding the duplicated
cleanup in the probe path after caam_remove(), which has already cleaned
up the resources.

[ cut here ]
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/mm/vmalloc.c:1490 
__vunmap+0xcc/0xf4
Trying to vfree() nonexistent vm area (f240)
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 
si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif 
tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma 
imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi rc_cec 
snd_soc_fsl_spdif imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal 
dw_hdmi_ahb_audio dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: 
caam]
CPU: 0 PID: 2346 Comm: modprobe Tainted: GW   4.8.0-rc1+ #2014
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
[] (__warn) from [] (warn_slowpath_fmt+0x40/0x48)
[] (warn_slowpath_fmt) from [] (__vunmap+0xcc/0xf4)
[] (__vunmap) from [] (vunmap+0x4c/0x54)
[] (vunmap) from [] (__iounmap+0x2c/0x30)
[] (__iounmap) from [] (iounmap+0x1c/0x20)
[] (iounmap) from [] (caam_probe+0x3dc/0x1498 [caam])
[] (caam_probe [caam]) from [] 
(platform_drv_probe+0x58/0xb8)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x1fc/0x2b8)
[] (driver_probe_device) from [] 
(__driver_attach+0xbc/0xc0) r10: r8:bf24b000 r7: r6:ef215844 
r5:bf2490c4 r4:ef215810
[] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x90)
[] (bus_for_each_dev) from [] (driver_attach+0x24/0x28)
[] (driver_attach) from [] (bus_add_driver+0xf4/0x200)
[] (bus_add_driver) from [] (driver_register+0x80/0xfc)
[] (driver_register) from [] 
(__platform_driver_register+0x48/0x4c)
[] (__platform_driver_register) from [] 
(caam_driver_init+0x18/0x24 [caam])
[] (caam_driver_init [caam]) from [] 
(do_one_initcall+0x44/0x178)
[] (do_one_initcall) from [] (do_init_module+0x68/0x1d8)
[] (do_init_module) from [] (load_module+0x1974/0x20b0)
[] (load_module) from [] (SyS_finit_module+0x94/0xa0)
[] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c)
---[ end trace 34e3370d88bb1786 ]---
[ cut here ]
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/drivers/clk/clk.c:594 
clk_core_disable+0xe4/0x26c
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 
si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif 
tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma 
imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi rc_cec 
snd_soc_fsl_spdif imx_pcm_dma videobuf2_vmalloc videobuf2_memops imx_thermal 
dw_hdmi_ahb_audio dw_hdmi_cec etnaviv fuse rc_pinnacle_pctv_hd [last unloaded: 
caam]
CPU: 0 PID: 2346 Comm: modprobe Tainted: GW   4.8.0-rc1+ #2014
Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
[] (show_stack) from [] (dump_stack+0xa4/0xdc)
[] (dump_stack) from [] (__warn+0xdc/0x108)
[] (__warn) from [] (warn_slowpath_null+0x28/0x30)
[] (warn_slowpath_null) from [] 
(clk_core_disable+0xe4/0x26c)
[] (clk_core_disable) from [] 
(clk_core_disable_lock+0x20/0x2c)
[] (clk_core_disable_lock) from [] (clk_disable+0x24/0x28)
[] (clk_disable) from [] (caam_probe+0x3fc/0x1498 [caam])
[] (caam_probe [caam]) from [] 
(platform_drv_probe+0x58/0xb8)
[] (platform_drv_probe) from [] 
(driver_probe_device+0x1fc/0x2b8)
[] (driver_probe_device) from [] 
(__driver_attach+0xbc/0xc0) r10: r8:bf24b000 r7: r6:ef215844 
r5:bf2490c4 r4:ef215810
[] (__driver_attach) from [] (bus_for_each_dev+0x5c/0x90)
[] (bus_for_each_dev) from [] (driver_attach+0x24/0x28)
[] (driver_attach) from [] (bus_add_driver+0xf4/0x200)
[] (bus_add_driver) from [] (driver_register+0x80/0xfc)
[] (driver_register) from [] 
(__platform_driver_register+0x48/0x4c)
[] (__platform_driver_register) from [] 
(caam_driver_init+0x18/0x24 [caam])
[] (caam_driver_init [caam]) from [] 
(do_one_initcall+0x44/0x178)
[] (do_one_initcall) from [] (do_init_module+0x68/0x1d8)
[] (do_init_module) from [] (load_module+0x1974/0x20b0)
[] (load_module) from [] (SyS_finit_module+0x94/0xa0)
[] (SyS_finit_module) from [] (ret_fast_syscall+0x0/0x1c)
---[ end trace 34e3370d88bb1787 ]---
[ cut here ]
WARNING: CPU: 0 PID: 2346 at /home/rmk/git/linux-rmk/drivers/clk/clk.c:476 
clk_core_unprepare+0x204/0x388
Modules linked in: caam(+) cbc rfcomm bnep bluetooth nfsd em28xx_rc si2157 
si2168 em28xx_dvb uvcvideo snd_soc_imx_sgtl5000 em28xx snd_soc_imx_spdif 
tveeprom snd_soc_fsl_asoc_card snd_soc_imx_audmux snd_soc_sgtl5000 imx_sdma 
imx2_wdt coda v4l2_mem2mem videobuf2_dma_contig snd_soc_fsl_ssi 

Re: AF_ALG broken?

[Russell King - ARM Linux]

On Tue, Aug 09, 2016 at 03:14:02PM +0800, Herbert Xu wrote:
> On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
> > 
> > I thought I gave the commands and link to your example code.  The
> > openssl case is md5, though sha* also gives the same result.  Your
> > example code was sha1 iirc.  I guess none of these would be using
> > HMAC - the openssl cases used to give results compatible with the
> > md5sum/ sha1sum etc userspace commands.
> > 
> > /proc/crypto:
> > 
> > name : md5
> > driver   : md5-caam
> 
> Right, caam is providing a setkey function for md5, which leads the
> API to think that a key is required.  We should fix it so that setkey
> is only set for the HMAC-variant.

Thanks, that works nicely again, and passes my tests.

8<
From: Russell King 
Subject: [PATCH] crypto: caam - fix non-hmac hashes

Since 6de62f15b581 ("crypto: algif_hash - Require setkey before
accept(2)"), the AF_ALG interface requires userspace to provide a key
to any algorithm that has a setkey method.  However, the non-HMAC
algorithms are not keyed, so setting a key is unnecessary.

Fix this by removing the setkey method from the non-keyed hash
algorithms.

Fixes: 6de62f15b581 ("crypto: algif_hash - Require setkey before accept(2)")
Cc: 
Signed-off-by: Russell King 
---
 drivers/crypto/caam/caamhash.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index ea284e3909ef..9d7fc9ec0b7e 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -1950,6 +1950,7 @@ caam_hash_alloc(struct caam_hash_template *template,
 template->name);
snprintf(alg->cra_driver_name, CRYPTO_MAX_ALG_NAME, "%s",
 template->driver_name);
+   t_alg->ahash_alg.setkey = NULL;
}
alg->cra_module = THIS_MODULE;
alg->cra_init = caam_hash_cra_init;
-- 
2.1.0

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/2] ath9k: disable RNG by default

[Stephan Mueller]

Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb miaoq...@codeaurora.org:

Hi Miaoqing,

> From: Miaoqing Pan 
> 
> ath9k RNG will dominates all the noise sources from the real HW
> RNG, disable it by default. But we strongly recommand to enable
> it if the system without HW RNG, especially on embedded systems.
> 
> Signed-off-by: Miaoqing Pan 

As a short term solution:

Acked-by: Stephan Mueller 

But as Jason outlined, there should be nothing that prevents using this code 
with the HW Random framework. This framework also has logic to limit the rate 
of injection and allows the setting of the entropy threshold at runtime.

> ---
>  drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
>  config ATH9K_HWRNG
>   bool "Random number generator support"
>   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
>   ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)



Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: AF_ALG broken?

[Herbert Xu]

On Tue, Aug 09, 2016 at 08:08:59AM +0100, Russell King - ARM Linux wrote:
> 
> I thought I gave the commands and link to your example code.  The
> openssl case is md5, though sha* also gives the same result.  Your
> example code was sha1 iirc.  I guess none of these would be using
> HMAC - the openssl cases used to give results compatible with the
> md5sum/ sha1sum etc userspace commands.
> 
> /proc/crypto:
> 
> name : md5
> driver   : md5-caam

Right, caam is providing a setkey function for md5, which leads the
API to think that a key is required.  We should fix it so that setkey
is only set for the HMAC-variant.

Thanks,
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] ath9k: disable RNG by default

[miaoqing]

From: Miaoqing Pan 

ath9k RNG will dominates all the noise sources from the real HW
RNG, disable it by default. But we strongly recommand to enable
it if the system without HW RNG, especially on embedded systems.

Signed-off-by: Miaoqing Pan 
---
 drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/Kconfig 
b/drivers/net/wireless/ath/ath9k/Kconfig
index f68cb00..8f231c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
 config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
-   default y
+   default n
---help---
  This option incorporates the ADC register output as a source of
  randomness into Linux entropy pool (/dev/urandom and /dev/random)
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] ath9k: change entropy formula for easier understanding

[miaoqing]

From: Miaoqing Pan 

The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.

Signed-off-by: Miaoqing Pan 
---
 drivers/net/wireless/ath/ath9k/rng.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/ath/ath9k/rng.c 
b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
 #include "ar9003_phy.h"
 
 #define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x)   (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x)   (((x) * 8 * 10) >> 5) /* quality: 10/32 */
 
 static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
 {
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

[Pan, Miaoqing]

Hi Jason, Stephan,

Agree with Jason's point, also  understand Stephan's concern.  The date rate 
can be roughly estimated by 'cat /dev/random |rngtest -c 1000',  the average 
speed is .294Kibits/s. I will sent the patch to disable ath9k RNG by 
default. 

Thanks,
Miaoqing

-Original Message-
From: Jason Cooper [mailto:ja...@lakedaemon.net] 
Sent: Tuesday, August 09, 2016 1:30 AM
To: Stephan Mueller 
Cc: Pan, Miaoqing ; Ted Tso ; 
Sepehrdad, Pouyan ; herb...@gondor.apana.org.au; 
linux-ker...@vger.kernel.org; linux-crypto@vger.kernel.org; ath9k-devel 
; linux-wirel...@vger.kernel.org; 
ath9k-de...@lists.ath9k.org; Kalle Valo 
Subject: Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy

Hi Stephan, Miaoqing Pan,

On Mon, Aug 08, 2016 at 08:41:36AM +0200, Stephan Mueller wrote:
> Am Montag, 8. August 2016, 02:03:36 CEST schrieb Pan, Miaoqing:
> > The entropy was evaluated by crypto expert,  the analysis report 
> > show the ADC with at least 10bits and up to 22 bits of min-entropy 
> > for a 32 bits value, we conservatively assume the min-entropy is 10 
> > bits out of 32 bits, so that's why set entropy quality  to  320/1024 = 
> > 10/32.

Ok, so the relevant commit is:

  ed14dc0af7cce ath9k: feeding entropy in kernel from ADC capture

Which refers to a previous commit:

  6301566e0b2d ath9k: export HW random number generator

> > Also we have explained in the commit message why can't use the HW 
> > RNG framework.

>From ed14dc0af7cce:

"""
Since ADC was not designed to be a dedicated HW RNG, we do not want to bind it 
to /dev/hwrng framework directly.
"""

> Where is the description of the RNG, where is the test implementation? 
> > 
> > Otherwise, your patch will cause high CPU load,  as continuously 
> > read ADC data if entropy bits under write_wakeup_threshold.
> 
> The issue is that although you may have analyzed it, others are unable 
> to measure the quality of the RNG and assess the design as well as the 
> implementation of the RNG. This RNG is the only implementation of a 
> hardware RNG that per default and without being able to change it at 
> runtime injects data into the input_pool where the noise source cannot 
> be audited. Note, even other respected RNG noise sources like the 
> Intel RDRAND will not feed into / dev/random per default in a way that 
> dominates all other noise sources.
> 
> I would like to be able to deactivate that noise source to the extent 
> that it does not cause /dev/random to unblock. The reason is that your 
> noise source starts to dominate all other noise sources.

I think the short-term problem here is the config logic:

config ATH9K_HWRNG
   bool "Random number generator support"
   depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
   default y

If you have *any* hwrngs you want to use and you have an ath9k card (HW_RANDOM 
= y and ATH9K != n), you get the behavior Stephan is pointing out.

Short term, we should just default no here.

> If you think that this patch is a challenge because your driver starts 
> to spin, please help and offer another solution.

Well, I don't buy the reasoning listed above for not using the hwrng framework. 
 Interrupt timings were never designed to be a source of entropy either.  We 
need to grab it where ever we can find it, especially on embedded systems.  
Documentation/hw_random.txt even says:

"""
This data is NOT CHECKED by any fitness tests, and could potentially be bogus 
(if the hardware is faulty or has been tampered with).
"""

I really don't think there's a problem with adding these sorts of sources under 
char/hw_random/.  I think the only thing we would be concerned about, other 
than the already addressed entropy estimation, would be constraining the data 
rate.

Is ath9k the only wireless card that exposes ADC registers?  What about sound 
cards?

thx,

Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html