* Re: [PATCH v3] KEYS: add SP800-56A KDF support for DH
From: Mat Martineau @ 2016-08-09 22:48 UTC (permalink / raw)
To: Stephan Mueller; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <2623005.lF82gu89UT@positron.chronox.de>
On Sat, 6 Aug 2016, Stephan Mueller wrote:
> diff --git a/security/keys/internal.h b/security/keys/internal.h
> index a705a7d..7659b52 100644
> --- a/security/keys/internal.h
> +++ b/security/keys/internal.h
> @@ -259,15 +259,32 @@ static inline long keyctl_get_persistent(uid_t uid, key_serial_t destring)
> #endif
>
> #ifdef CONFIG_KEY_DH_OPERATIONS
> +#include <crypto/rng.h>
> +#include <linux/compat.h>
These may belong at the top of the file, even if they are only used when
CONFIG_KEY_DH_OPERATIONS is defined.
> 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
^ permalink raw reply
* Re: [PATCH v3] DH support: add KDF handling support
From: Mat Martineau @ 2016-08-09 22:38 UTC (permalink / raw)
To: Stephan Mueller; +Cc: David Howells, keyrings, linux-crypto
In-Reply-To: <3715151.LOyK4NLlGi@positron.chronox.de>
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
^ permalink raw reply
* Re: [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test
From: Tapas Sarangi @ 2016-08-09 21:59 UTC (permalink / raw)
To: Stephan Mueller; +Cc: herbert@gondor.apana.org.au, linux-crypto@vger.kernel.org
In-Reply-To: <6079382.fWeFLzBGfE@positron.chronox.de>
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=100000
[ 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" <smueller@chronox.de> 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 <TSarangi@trustwave.com>
>Signed-off-by: Stephan Mueller <smueller@chronox.de>
>---
> 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->drbg_mutex);
>+ drbg->core = &drbg_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(&addtl, 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, &addtl, coreref, pr);
>+ ret = drbg_seed(drbg, &addtl, 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.
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Henrique de Moraes Holschuh @ 2016-08-09 20:18 UTC (permalink / raw)
To: Jason Cooper; +Cc: Herbert Xu, Keith Packard, linux-crypto, linux-kernel
In-Reply-To: <20160809165710.GC2013@io.lakedaemon.net>
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
^ permalink raw reply
* [PATCH] crypto: DRBG: do not call drbg_instantiate in healt test
From: Stephan Mueller @ 2016-08-09 19:02 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: herbert, linux-crypto@vger.kernel.org
In-Reply-To: <2671088.6l5BeQPtPO@positron.chronox.de>
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 <TSarangi@trustwave.com>
Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
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->drbg_mutex);
+ drbg->core = &drbg_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(&addtl, 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, &addtl, coreref, pr);
+ ret = drbg_seed(drbg, &addtl, 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
^ permalink raw reply related
* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Keith Packard @ 2016-08-09 19:01 UTC (permalink / raw)
To: Jason Cooper; +Cc: Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <20160809182620.GF2013@io.lakedaemon.net>
[-- Attachment #1: Type: text/plain, Size: 2188 bytes --]
Jason Cooper <jason@lakedaemon.net> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 810 bytes --]
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Jason Cooper @ 2016-08-09 18:26 UTC (permalink / raw)
To: Keith Packard; +Cc: Herbert Xu, linux-crypto, linux-kernel
In-Reply-To: <86y445rfiq.fsf@hiro.keithp.com>
Hi Keith,
On Tue, Aug 09, 2016 at 10:58:05AM -0700, Keith Packard wrote:
> Jason Cooper <jason@lakedaemon.net> 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.
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Keith Packard @ 2016-08-09 17:58 UTC (permalink / raw)
To: Jason Cooper, Herbert Xu; +Cc: linux-crypto, linux-kernel
In-Reply-To: <20160809165710.GC2013@io.lakedaemon.net>
[-- Attachment #1: Type: text/plain, Size: 881 bytes --]
Jason Cooper <jason@lakedaemon.net> 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 810 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:51 UTC (permalink / raw)
To: Henrique de Moraes Holschuh
Cc: Stephan Mueller, Herbert Xu, Pan, Miaoqing, Matt Mackall,
miaoqing@codeaurora.org, Valo, Kalle,
linux-wireless@vger.kernel.org, ath9k-devel,
linux-crypto@vger.kernel.org, Sepehrdad, Pouyan
In-Reply-To: <20160809102458.GA20214@khazad-dum.debian.net>
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.GC2013@io.lakedaemon.net
and top of thread:
https://lkml.kernel.org/r/1469477255-26824-1-git-send-email-keithp@keithp.com
thx,
Jason.
^ permalink raw reply
* Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'
From: Stephan Mueller @ 2016-08-09 17:52 UTC (permalink / raw)
To: Tapas Sarangi, herbert; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF7805.2937%tsarangi@trustwave.com>
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
^ permalink raw reply
* Re: [PATCH 2/2] ath9k: disable RNG by default
From: Jason Cooper @ 2016-08-09 17:48 UTC (permalink / raw)
To: miaoqing-sgV2jX0FEOL9JmXXK+q4OQ
Cc: kvalo-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA,
ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
smueller-T9tCv8IpfcWELgA04lAiVw, pouyans-Rm6X0d1/PG5y9aJCnZT0Uw
In-Reply-To: <1470726147-30095-2-git-send-email-miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
On Tue, Aug 09, 2016 at 03:02:27PM +0800, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org wrote:
> From: Miaoqing Pan <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
>
> 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 <miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org>
Until we get the hw_random/get_device_randomness question sorted...
Reviewed-by: Jason Cooper <jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org>
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'
From: Tapas Sarangi @ 2016-08-09 17:11 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <1699099.iu8Xr4xQ6X@tauon.atsec.com>
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 <smueller@chronox.de>
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" <smueller@chronox.de> 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.
^ permalink raw reply
* Re: FIPS mode: modprobe: ERROR: could not insert 'drbg'
From: Stephan Mueller @ 2016-08-09 17:05 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF7065.28F3%tsarangi@trustwave.com>
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
^ permalink raw reply
* Re: [PATCH] hwrng: core - Allow for multiple simultaneous active hwrng devices
From: Jason Cooper @ 2016-08-09 16:57 UTC (permalink / raw)
To: Herbert Xu; +Cc: Keith Packard, linux-crypto, linux-kernel
In-Reply-To: <20160809095058.GA6618@gondor.apana.org.au>
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 <keithp@keithp.com>
>
> 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.
^ permalink raw reply
* FIPS mode: modprobe: ERROR: could not insert 'drbg'
From: Tapas Sarangi @ 2016-08-09 16:34 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
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=0x00000100
[ 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] 0000000000000000 ffff88003e1dfbc8 ffffffff812ae299
0000000000000001
[ 1.336114] 0000000000000001 ffffffff81716b00 ffff88003e210000
ffff88003e1dfc48
[ 1.336114] ffffffff81104fd4 0000000000000010 ffff88003e1dfc58
ffff88003e1dfbf8
[ 1.336114] Call Trace:
[ 1.336114] [<ffffffff812ae299>] dump_stack+0x51/0x78
[ 1.336114] [<ffffffff81104fd4>] panic+0xc1/0x211
[ 1.336114] [<ffffffff81058781>] forget_original_parent+0x411/0x420
[ 1.336114] [<ffffffff810f4a12>] ? perf_pin_task_context+0x12/0x40
[ 1.336114] [<ffffffff810fcd52>] ? perf_event_exit_task+0x3b2/0x470
[ 1.336114] [<ffffffff81058cb6>] exit_notify+0x36/0x1e0
[ 1.336114] [<ffffffff810d4b61>] ? cgroup_exit+0x71/0xc0
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff8105a4ff>] do_exit+0x31f/0x640
[ 1.336114] [<ffffffff811726d9>] ? ____fput+0x9/0x10
[ 1.336114] [<ffffffff81070fdf>] ? task_work_run+0x5f/0x90
[ 1.336114] [<ffffffff81046d0e>] ? __do_page_fault+0x17e/0x450
[ 1.336114] [<ffffffff8105a869>] do_group_exit+0x49/0xb0
[ 1.336114] [<ffffffff8105a8e2>] SyS_exit_group+0x12/0x20
[ 1.336114] [<ffffffff8154dd9b>] entry_SYSCALL_64_fastpath+0x13/0x8f
[ 1.336114] Kernel Offset: disabled
[ 1.336114] ---[ end Kernel panic - not syncing: Attempted to kill
init! exitcode=0x00000100
[ 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
CONFIG_CRYPTO_JITTERENTROPY=m
CONFIG_CRYPTO_USER_API=m
CONFIG_CRYPTO_USER_API_HASH=m
CONFIG_CRYPTO_USER_API_SKCIPHER=m
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
CONFIG_CRYPTO_DEV_PADLOCK=m
CONFIG_CRYPTO_DEV_PADLOCK_AES=m
CONFIG_CRYPTO_DEV_PADLOCK_SHA=m
CONFIG_CRYPTO_DEV_CCP=y
CONFIG_CRYPTO_DEV_CCP_DD=m
CONFIG_CRYPTO_DEV_CCP_CRYPTO=m
CONFIG_CRYPTO_DEV_QAT=m
CONFIG_CRYPTO_DEV_QAT_DH895xCC=m
________________________________
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is strictly prohibited. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 16:08 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: dhowells@redhat.com, linux-crypto@vger.kernel.org
In-Reply-To: <D3CF6958.28A9%tsarangi@trustwave.com>
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=0x00000100
> [ 1.195820]
>
>
> -Tapas
>
>
>
> On 8/9/16, 10:00 AM, "Tapas Sarangi" <TSarangi@trustwave.com> 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" <smueller@chronox.de> 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
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 16:07 UTC (permalink / raw)
To: Stephan Mueller, dhowells@redhat.com; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF597F.289B%tsarangi@trustwave.com>
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=0x00000100
[ 1.195820]
-Tapas
On 8/9/16, 10:00 AM, "Tapas Sarangi" <TSarangi@trustwave.com> 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" <smueller@chronox.de> 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.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 15:00 UTC (permalink / raw)
To: Stephan Mueller, dhowells@redhat.com; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <21317106.O9C0GvNNQc@positron.chronox.de>
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" <smueller@chronox.de> 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.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 14:55 UTC (permalink / raw)
To: Tapas Sarangi, dhowells; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF5455.2887%tsarangi@trustwave.com>
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
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:54 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF5455.2887%tsarangi@trustwave.com>
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" <TSarangi@trustwave.com> 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" <smueller@chronox.de> 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.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:39 UTC (permalink / raw)
To: Stephan Mueller; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <2825660.AnRQGUh0XD@tauon.atsec.com>
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" <smueller@chronox.de> 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.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Gary R Hook @ 2016-08-09 14:36 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF4E8C.2883%tsarangi@trustwave.com>
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.
^ permalink raw reply
* Re: RSA key size not allowed in FIPS
From: Stephan Mueller @ 2016-08-09 14:29 UTC (permalink / raw)
To: Tapas Sarangi; +Cc: linux-crypto@vger.kernel.org
In-Reply-To: <D3CF4E8C.2883%tsarangi@trustwave.com>
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
^ permalink raw reply
* RSA key size not allowed in FIPS
From: Tapas Sarangi @ 2016-08-09 14:10 UTC (permalink / raw)
To: linux-crypto@vger.kernel.org
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
0000000000000068
[ 0.803075] IP: [<ffffffff811e1ad7>] kernfs_find_ns+0x17/0xf0
[ 0.804111] PGD 0
[ 0.804111] Oops: 0000 [#1] SMP
[ 0.804111] Modules linked in:
[ 0.804111] CPU: 0 PID: 6 Comm: kworker/u2:0 Tainted: G W
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: ffff88003e214100 ti: ffff88003e264000 task.ti:
ffff88003e264000
[ 0.804111] RIP: 0010:[<ffffffff811e1ad7>] [<ffffffff811e1ad7>]
kernfs_find_ns+0x17/0xf0
[ 0.804111] RSP: 0018:ffff88003e267868 EFLAGS: 00010282
[ 0.804111] RAX: ffff88003e214100 RBX: 0000000000000000 RCX:
ffff88003e264008
[ 0.804111] RDX: 0000000000000000 RSI: ffffffff8166bb80 RDI:
0000000000000000
[ 0.804111] RBP: ffff88003e267898 R08: 0000000000000000 R09:
ffffffff8166bb80
[ 0.804111] R10: 00000000000c6000 R11: 0000000000000001 R12:
ffffffff8166bb80
[ 0.804111] R13: 0000000000000000 R14: ffffffff8173048a R15:
ffff88003b17b1a0
[ 0.804111] FS: 0000000000000000(0000) GS:ffff88003fc00000(0000)
knlGS:0000000000000000
[ 0.804111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 0.804111] CR2: 0000000000000068 CR3: 0000000001806000 CR4:
00000000000406f0
[ 0.804111] Stack:
[ 0.804111] ffff88003e267898 0000000000000000 ffff880000000001
0000000000000000
[ 0.804111] ffffffff8166bb80 0000000000000000 ffff88003e2678c8
ffffffff811e1e77
[ 0.804111] 0000000000000096 ffffffff81873d40 ffff88003b152828
0000000000000005
[ 0.804111] Call Trace:
[ 0.804111] [<ffffffff811e1e77>] kernfs_find_and_get_ns+0x37/0x60
[ 0.804111] [<ffffffff811e5c58>] sysfs_unmerge_group+0x18/0x60
[ 0.804111] [<ffffffff8139c187>] 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.
^ permalink raw reply
* Re: [PATCH v2] RANDOM: ATH9K RNG delivers zero bits of entropy
From: Jason Cooper @ 2016-08-09 14:04 UTC (permalink / raw)
To: Theodore Ts'o, Pan, Miaoqing, Stephan Mueller,
Sepehrdad, Pouyan, herbert@gondor.apana.org.au,
linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
ath9k-devel, linux-wireless@vger.kernel.org,
ath9k-devel@lists.ath9k.org, Kalle Valo
In-Reply-To: <20160809115622.GG9515@thunk.org>
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 +0000, 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 1111.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.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox