* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-09 9:37 ` Stephan Mueller
0 siblings, 0 replies; 48+ messages in thread
From: Stephan Mueller @ 2016-08-09 9:37 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ,
Valo, Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
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, &entropy) != 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-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 [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-09 9:37 ` Stephan Mueller
(?)
@ 2016-08-09 9:46 ` Herbert Xu
2016-08-09 9:56 ` Stephan Mueller
-1 siblings, 1 reply; 48+ messages in thread
From: Herbert Xu @ 2016-08-09 9:46 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, jason, Sepehrdad,
Pouyan
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, &entropy) != 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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-09 9:46 ` Herbert Xu
@ 2016-08-09 9:56 ` Stephan Mueller
2016-08-09 9:56 ` Herbert Xu
0 siblings, 1 reply; 48+ messages in thread
From: Stephan Mueller @ 2016-08-09 9:56 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, jason, Sepehrdad,
Pouyan
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
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-09 9:56 ` Stephan Mueller
@ 2016-08-09 9:56 ` Herbert Xu
2016-08-09 10:06 ` Stephan Mueller
0 siblings, 1 reply; 48+ messages in thread
From: Herbert Xu @ 2016-08-09 9:56 UTC (permalink / raw)
To: Stephan Mueller
Cc: Pan, Miaoqing, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, jason, Sepehrdad,
Pouyan
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 <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-09 9:56 ` Herbert Xu
@ 2016-08-09 10:06 ` Stephan Mueller
2016-08-09 10:24 ` Henrique de Moraes Holschuh
0 siblings, 1 reply; 48+ messages in thread
From: Stephan Mueller @ 2016-08-09 10:06 UTC (permalink / raw)
To: Herbert Xu
Cc: Pan, Miaoqing, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, jason, Sepehrdad,
Pouyan
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
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-09 10:24 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 48+ messages in thread
From: Henrique de Moraes Holschuh @ 2016-08-09 10:24 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Pan, Miaoqing, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, jason, Sepehrdad,
Pouyan
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
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-09 10:24 ` Henrique de Moraes Holschuh
0 siblings, 0 replies; 48+ messages in thread
From: Henrique de Moraes Holschuh @ 2016-08-09 10:24 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Pan, Miaoqing, Matt Mackall,
miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo, Kalle,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
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-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 [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-09 10:24 ` Henrique de Moraes Holschuh
(?)
@ 2016-08-09 17:51 ` Jason Cooper
-1 siblings, 0 replies; 48+ messages in thread
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, Valo, Kalle, linux-wireless, ath9k-devel, linux-crypto,
Sepehrdad, Pouyan
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 [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 2:35 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 2:35 UTC (permalink / raw)
To: Stephan Mueller, Herbert Xu
Cc: Matt Mackall, miaoqing, Valo, Kalle, linux-wireless, ath9k-devel,
linux-crypto, jason, Sepehrdad, Pouyan
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 <= &buf[FIPS_RNG_BUFFER_SIZE];
p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}
--
Miaoqing
________________________________________
From: Stephan Mueller <smueller@chronox.de>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoqing@codeaurora.org; Valo, Kalle; linux-wireless@vger.kernel.org; ath9k-devel; linux-crypto@vger.kernel.org; jason@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, &entropy) != 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
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 2:35 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 2:35 UTC (permalink / raw)
To: Stephan Mueller, Herbert Xu
Cc: Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo, Kalle,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
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 <= &buf[FIPS_RNG_BUFFER_SIZE];
p += random_step) {
random_add_entropy(p, random_step);
random_sleep();
}
return 0;
}
--
Miaoqing
________________________________________
From: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan
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, &entropy) != 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-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 [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 5:29 ` Stephan Mueller
0 siblings, 0 replies; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 5:29 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi 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 <= &buf[FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use
add_device_randomness.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 5:29 ` Stephan Mueller
0 siblings, 0 replies; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 5:29 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi 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 <= &buf[FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use
add_device_randomness.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 6:04 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 6:04 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Hi Stephan,
FIPS RNG test is supposed to be run on the output of an RNG, and not on the RNG entropy source. It is not surprising that the RNG input fails the entropy tests from NIST. Check the following example.
Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each a_i is a byte. And imagine, this sequence passes all randomness tests.
Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n, where each zero is a byte
If you give this sequence (as an entropy source) to a randomness test, it will fail most of the tests, if not all. This does not mean this sequence is not appropriate as an entropy source, it just means we need twice more bytes to gain the same amount of entropy.
I can give this 2n byte sequence to an RNG as an entropy source and it provides the same amount of security as if I give the n byte stream.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 1:29 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi 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 <= &buf[FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use add_device_randomness.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 6:04 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 6:04 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Hi Stephan,
FIPS RNG test is supposed to be run on the output of an RNG, and not on the RNG entropy source. It is not surprising that the RNG input fails the entropy tests from NIST. Check the following example.
Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each a_i is a byte. And imagine, this sequence passes all randomness tests.
Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n, where each zero is a byte
If you give this sequence (as an entropy source) to a randomness test, it will fail most of the tests, if not all. This does not mean this sequence is not appropriate as an entropy source, it just means we need twice more bytes to gain the same amount of entropy.
I can give this 2n byte sequence to an RNG as an entropy source and it provides the same amount of security as if I give the n byte stream.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org]
Sent: Wednesday, August 10, 2016 1:29 PM
To: Pan, Miaoqing <miaoqing-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 02:35:04 CEST schrieb Pan, Miaoqing:
Hi 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 <= &buf[FIPS_RNG_BUFFER_SIZE];
> p += random_step) {
> random_add_entropy(p, random_step);
> random_sleep();
> }
> return 0;
> }
Not even the poor cheap AIS20 statistical tests from rngd pass?
I guess the only sensible solution is what Ted suggested to use add_device_randomness.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-10 6:04 ` Pan, Miaoqing
(?)
@ 2016-08-10 6:25 ` Stephan Mueller
2016-08-10 6:46 ` Pan, Miaoqing
-1 siblings, 1 reply; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 6:25 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not on the
> RNG entropy source. It is not surprising that the RNG input fails the
> entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where each
> a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0, a_n,
> where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test, it
> will fail most of the tests, if not all. This does not mean this sequence
> is not appropriate as an entropy source, it just means we need twice more
> bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG
assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If
you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your
noise source to seed a DRNG from (i.e. have an entropy to data ratio of
significantly below 1). And the argument for the oversampling rate is always
a very interesting discussion. You apply 10/32. In private, I am wondering
about that ratio, but this should not be discussed here as I hope you have a
valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise
source before using it. Your current implementation simply does not allow
switching the noise source off to feed the input_pool with data that
increases the entropy estimator (at runtime).
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 6:46 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 6:46 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Hi Stephan,
Would you please provide a recent NIST document which asks the entropy source to pass the NIST randomness tests ?
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 2:25 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not
> on the RNG entropy source. It is not surprising that the RNG input
> fails the entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where
> each a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0,
> a_n, where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test,
> it will fail most of the tests, if not all. This does not mean this
> sequence is not appropriate as an entropy source, it just means we
> need twice more bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your noise source to seed a DRNG from (i.e. have an entropy to data ratio of significantly below 1). And the argument for the oversampling rate is always a very interesting discussion. You apply 10/32. In private, I am wondering about that ratio, but this should not be discussed here as I hope you have a valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise source before using it. Your current implementation simply does not allow switching the noise source off to feed the input_pool with data that increases the entropy estimator (at runtime).
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 6:46 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 6:46 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Hi Stephan,
Would you please provide a recent NIST document which asks the entropy source to pass the NIST randomness tests ?
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org]
Sent: Wednesday, August 10, 2016 2:25 PM
To: Pan, Miaoqing <miaoqing-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:04:32 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> FIPS RNG test is supposed to be run on the output of an RNG, and not
> on the RNG entropy source. It is not surprising that the RNG input
> fails the entropy tests from NIST. Check the following example.
>
> Imagine you have a perfectly random sequence, a_1, a_2, .., a_n, where
> each a_i is a byte. And imagine, this sequence passes all randomness tests.
>
> Now, let's say I create a new sequence a_1, 0, a_2, 0, a_3, 0, ..., 0,
> a_n, where each zero is a byte
>
> If you give this sequence (as an entropy source) to a randomness test,
> it will fail most of the tests, if not all. This does not mean this
> sequence is not appropriate as an entropy source, it just means we
> need twice more bytes to gain the same amount of entropy.
Agreed. But that is a very simplistic view.
>
> I can give this 2n byte sequence to an RNG as an entropy source and it
> provides the same amount of security as if I give the n byte stream.
Well, I am working with standards bodies like NIST and BSI on RNG assessments. They all require that the noise source (pre-whitening, of
course) pass statistical tests like the AIS20 tests, SP800-22 and similar. If you fail, you better have a good argument.
And the only argument that is kind of allowed is that you oversample your noise source to seed a DRNG from (i.e. have an entropy to data ratio of significantly below 1). And the argument for the oversampling rate is always a very interesting discussion. You apply 10/32. In private, I am wondering about that ratio, but this should not be discussed here as I hope you have a valid argument for that.
As we are talking about the current rngd, we have to consider that it does
*not* perform an oversampling (yet) as mentioned in the previous emails.
Do not get me wrong on my initial patch: your RNG may provide some entropy.
But there are quite some folks who want to understand and audit a noise source before using it. Your current implementation simply does not allow switching the noise source off to feed the input_pool with data that increases the entropy estimator (at runtime).
Ciao
Stephan
--
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 [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-10 6:46 ` Pan, Miaoqing
(?)
@ 2016-08-10 6:51 ` Stephan Mueller
2016-08-10 7:15 ` Pan, Miaoqing
-1 siblings, 1 reply; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 6:51 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
2016-08-10 6:51 ` Stephan Mueller
@ 2016-08-10 7:15 ` Pan, Miaoqing
2016-08-10 7:27 ` Stephan Mueller
0 siblings, 1 reply; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 7:15 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Hi Stephan,
NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the amount of min entropy the source provides, and not to decide if the source has passed the tests or failed. See
https://github.com/usnistgov/SP800-90B_EntropyAssessment
The goal is often to make sure the input entropy is more than the entropy we expect from the output.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 2:52 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 06:46:31 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> Would you please provide a recent NIST document which asks the entropy
> source to pass the NIST randomness tests ?
See FIPS 140-2 IG 7.15 which explicitly references SP800-22.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:27 ` Stephan Mueller
0 siblings, 0 replies; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 7:27 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the
> amount of min entropy the source provides, and not to decide if the source
> has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the entropy we
> expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the
binary decision). Yet, SP800-22 with the associated tool delivers a binary
decision.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:27 ` Stephan Mueller
0 siblings, 0 replies; 48+ messages in thread
From: Stephan Mueller @ 2016-08-10 7:27 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate the
> amount of min entropy the source provides, and not to decide if the source
> has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the entropy we
> expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the
binary decision). Yet, SP800-22 with the associated tool delivers a binary
decision.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:40 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 7:40 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:40 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 7:40 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:43 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 7:43 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle, linux-wireless,
ath9k-devel, linux-crypto, jason, Sepehrdad, Pouyan
Hi Stephan,
The problem with using the add_device_randomness is that we do not know when to call that API, and we have to make our solution either timer-based or interrupt based, which is not really the correct way of implementing this feature.
Thanks,
Miaoqing
-----Original Message-----
From: Pan, Miaoqing
Sent: Wednesday, August 10, 2016 3:41 PM
To: Stephan Mueller <smueller@chronox.de>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller@chronox.de]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing@qti.qualcomm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>; Matt Mackall <mpm@selenic.com>; miaoqing@codeaurora.org; Valo, Kalle <kvalo@qca.qualcomm.com>; linux-wireless@vger.kernel.org; ath9k-devel <ath9k-devel@qca.qualcomm.com>; linux-crypto@vger.kernel.org; jason@lakedaemon.net; Sepehrdad, Pouyan <pouyans@qti.qualcomm.com>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
^ permalink raw reply [flat|nested] 48+ messages in thread
* RE: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 7:43 ` Pan, Miaoqing
0 siblings, 0 replies; 48+ messages in thread
From: Pan, Miaoqing @ 2016-08-10 7:43 UTC (permalink / raw)
To: Stephan Mueller
Cc: Herbert Xu, Matt Mackall, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
jason-NLaQJdtUoK4Be96aLqz0jA, Sepehrdad, Pouyan
Hi Stephan,
The problem with using the add_device_randomness is that we do not know when to call that API, and we have to make our solution either timer-based or interrupt based, which is not really the correct way of implementing this feature.
Thanks,
Miaoqing
-----Original Message-----
From: Pan, Miaoqing
Sent: Wednesday, August 10, 2016 3:41 PM
To: Stephan Mueller <smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: RE: [PATCH 2/2] ath9k: disable RNG by default
Hi Stephan,
That is set as "optional but highly recommended" in the FIPS doc, plus the fact that we do not have a requirement to have a FIP-approved RNG in our case. Although FIPS might impose higher and stronger requirements on the source of entropy, but not passing those tests does not mean the source of entropy is of bad quality. As I mentioned earlier, we just need to evaluate the amount of entropy it provides correctly and use it accordingly. If we are dealing with a chip which has a HW RNG, we expect extremely high entropy close to full from our source, but this patch is for chips which do not have a dedicated HW RNG in place to improve the quality of random number generation on the platform.
Thanks,
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:smueller-T9tCv8IpfcWELgA04lAiVw@public.gmane.org]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <miaoqing-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>; Matt Mackall <mpm-VDJrAJ4Gl5ZBDgjK7y7TUQ@public.gmane.org>; miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org; Valo, Kalle <kvalo-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-wireless-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; ath9k-devel <ath9k-devel-A+ZNKFmMK5xy9aJCnZT0Uw@public.gmane.org>; linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org; jason-NLaQJdtUoK4Be96aLqz0jA@public.gmane.org; Sepehrdad, Pouyan <pouyans-Rm6X0d1/PG5y9aJCnZT0Uw@public.gmane.org>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Mittwoch, 10. August 2016, 07:15:49 CEST schrieb Pan, Miaoqing:
Hi Miaoqing,
> Hi Stephan,
>
> NIST SP 800-22-rev1a and NIST SP 800-90B are used together to evaluate
> the amount of min entropy the source provides, and not to decide if
> the source has passed the tests or failed. See
>
> https://github.com/usnistgov/SP800-90B_EntropyAssessment
>
> The goal is often to make sure the input entropy is more than the
> entropy we expect from the output.
You are correct on the SP800-90B tests (hence I did not refer to them for the binary decision). Yet, SP800-22 with the associated tool delivers a binary decision.
Ciao
Stephan
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 13:24 ` Jason Cooper
0 siblings, 0 replies; 48+ messages in thread
From: Jason Cooper @ 2016-08-10 13:24 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Stephan Mueller, Herbert Xu, Matt Mackall, miaoqing, Valo, Kalle,
linux-wireless, ath9k-devel, linux-crypto, Sepehrdad, Pouyan
Hi Miaoqing Pan, Stephen,
*gentle reminder: others are reading which may not be directly included
in the conversation. Including the archives. Please avoid top posting.
:)
On Wed, Aug 10, 2016 at 07:43:45AM +0000, Pan, Miaoqing wrote:
> The problem with using the add_device_randomness is that we do not
> know when to call that API, and we have to make our solution either
> timer-based or interrupt based, which is not really the correct way of
> implementing this feature.
Exactly. I think we're dancing around the problem by discussing the
quality of what the ath9k adc provides.
The fact is, barring userspace expectations of /dev/hwrng, hw_random is
the appropriate place for it. It's not a devicetree blob, mac address,
or pci config space. Which are things we feed in once for the heck of
it. This is a *continuous* source or questionable quality.
I'm seriously considering putting this and timeriomem-rng into a
subdirectory under hw_random/, maybe environ/. Anything in there gets
quality=0 for default, and *doesn't* contribute to /dev/hwrng.
Regardless which path we take, I think we should include 'adc' in the
name. I've heard countless times about "Atheros cards come with an rng
on board". :-/
thx,
Jason.
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-10 13:24 ` Jason Cooper
0 siblings, 0 replies; 48+ messages in thread
From: Jason Cooper @ 2016-08-10 13:24 UTC (permalink / raw)
To: Pan, Miaoqing
Cc: Stephan Mueller, Herbert Xu, Matt Mackall,
miaoqing-sgV2jX0FEOL9JmXXK+q4OQ, Valo, Kalle,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Sepehrdad, Pouyan
Hi Miaoqing Pan, Stephen,
*gentle reminder: others are reading which may not be directly included
in the conversation. Including the archives. Please avoid top posting.
:)
On Wed, Aug 10, 2016 at 07:43:45AM +0000, Pan, Miaoqing wrote:
> The problem with using the add_device_randomness is that we do not
> know when to call that API, and we have to make our solution either
> timer-based or interrupt based, which is not really the correct way of
> implementing this feature.
Exactly. I think we're dancing around the problem by discussing the
quality of what the ath9k adc provides.
The fact is, barring userspace expectations of /dev/hwrng, hw_random is
the appropriate place for it. It's not a devicetree blob, mac address,
or pci config space. Which are things we feed in once for the heck of
it. This is a *continuous* source or questionable quality.
I'm seriously considering putting this and timeriomem-rng into a
subdirectory under hw_random/, maybe environ/. Anything in there gets
quality=0 for default, and *doesn't* contribute to /dev/hwrng.
Regardless which path we take, I think we should include 'adc' in the
name. I've heard countless times about "Atheros cards come with an rng
on board". :-/
thx,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
2016-08-10 13:24 ` Jason Cooper
(?)
@ 2016-08-11 2:54 ` miaoqing
2016-08-11 13:14 ` Jason Cooper
-1 siblings, 1 reply; 48+ messages in thread
From: miaoqing @ 2016-08-11 2:54 UTC (permalink / raw)
To: Jason Cooper
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall, Valo,
Kalle, linux-wireless, ath9k-devel, linux-crypto, Sepehrdad,
Pouyan
Hi Jason,
On 2016-08-10 21:24, Jason Cooper wrote:
> *gentle reminder: others are reading which may not be directly included
> in the conversation. Including the archives. Please avoid top
> posting.
> :)
Thanks:)
> The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> the appropriate place for it. It's not a devicetree blob, mac address,
> or pci config space. Which are things we feed in once for the heck of
> it. This is a *continuous* source or questionable quality.
>
> I'm seriously considering putting this and timeriomem-rng into a
> subdirectory under hw_random/, maybe environ/. Anything in there gets
> quality=0 for default, and *doesn't* contribute to /dev/hwrng.
>
> Regardless which path we take, I think we should include 'adc' in the
> name. I've heard countless times about "Atheros cards come with an rng
> on board". :-/
If I understand correctly, you want to bind the ADC source to
/dev/hwrng,
and then change rng-tools to set the entropy to zero in the ioctl call ?
There are two major problems with that approach,
1) We already tried once before to bind our solution to /dev/hwrng, and
got
so much complaints. The conclusion was that maybe we know that the
output of
/dev/hwrng does not have perfect entropy, but a normal user does not
know and
will misuse it. You mentioned in
https://www.kernel.org/doc/Documentation/hw_random.txt
we have
"This data is NOT CHECKED by any
fitness tests, and could potentially be bogus (if the
hardware is faulty or has been tampered with). Data is only
output if the hardware "has-data" flag is set, but nevertheless
a security-conscious person would run fitness tests on the
data before assuming it is truly random."
But this is not enough to convince upstream to switch to /dev/hwrng. I
think the
concern of users misusing the solution is a very valid concern.
2) If we set the entropy to zero in rng-tools, we cannot tolerate the
load.
Rng-tools is not a timer-based solution. Similar to our solution, it is
based on
/proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
the entropy
counter, rng-tools keep writing into the pool, and both rng-tools and
WiFi chip will
be overloaded.
Thanks,
Miaoqing
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-11 13:14 ` Jason Cooper
0 siblings, 0 replies; 48+ messages in thread
From: Jason Cooper @ 2016-08-11 13:14 UTC (permalink / raw)
To: miaoqing
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall, Valo,
Kalle, linux-wireless, ath9k-devel, linux-crypto, Sepehrdad,
Pouyan
On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoqing@codeaurora.org wrote:
> On 2016-08-10 21:24, Jason Cooper wrote:
> >The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> >the appropriate place for it. It's not a devicetree blob, mac address,
> >or pci config space. Which are things we feed in once for the heck of
> >it. This is a *continuous* source or questionable quality.
> >
> >I'm seriously considering putting this and timeriomem-rng into a
> >subdirectory under hw_random/, maybe environ/. Anything in there gets
> >quality=0 for default, and *doesn't* contribute to /dev/hwrng.
> >
> >Regardless which path we take, I think we should include 'adc' in the
> >name. I've heard countless times about "Atheros cards come with an rng
> >on board". :-/
>
> If I understand correctly, you want to bind the ADC source to
> /dev/hwrng, and then change rng-tools to set the entropy to zero in
> the ioctl call ? There are two major problems with that approach,
Nope. I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently. The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.
If the environmental sources are the only sources, then no /dev/hwrng
should appear.
> 1) We already tried once before to bind our solution to /dev/hwrng,
> and got so much complaints. The conclusion was that maybe we know that
> the output of /dev/hwrng does not have perfect entropy, but a normal
> user does not know and will misuse it. You mentioned in
> https://www.kernel.org/doc/Documentation/hw_random.txt we have
>
> "This data is NOT CHECKED by any
> fitness tests, and could potentially be bogus (if the
> hardware is faulty or has been tampered with). Data is only
> output if the hardware "has-data" flag is set, but nevertheless
> a security-conscious person would run fitness tests on the
> data before assuming it is truly random."
>
> But this is not enough to convince upstream to switch to /dev/hwrng.
> I think the concern of users misusing the solution is a very valid
> concern.
Agreed.
> 2) If we set the entropy to zero in rng-tools, we cannot tolerate the
> load. Rng-tools is not a timer-based solution. Similar to our
> solution, it is based on
> /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
> the entropy counter, rng-tools keep writing into the pool, and both
> rng-tools and WiFi chip will be overloaded.
That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng. timeriomem-rng
should have the same problem ath9k-rng does.
Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.
thx,
Jason.
^ permalink raw reply [flat|nested] 48+ messages in thread
* Re: [PATCH 2/2] ath9k: disable RNG by default
@ 2016-08-11 13:14 ` Jason Cooper
0 siblings, 0 replies; 48+ messages in thread
From: Jason Cooper @ 2016-08-11 13:14 UTC (permalink / raw)
To: miaoqing-sgV2jX0FEOL9JmXXK+q4OQ
Cc: Pan, Miaoqing, Stephan Mueller, Herbert Xu, Matt Mackall, Valo,
Kalle, linux-wireless-u79uwXL29TY76Z2rM5mHXA, ath9k-devel,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Sepehrdad, Pouyan
On Thu, Aug 11, 2016 at 10:54:11AM +0800, miaoqing-sgV2jX0FEOL9JmXXK+q4OQ@public.gmane.org wrote:
> On 2016-08-10 21:24, Jason Cooper wrote:
> >The fact is, barring userspace expectations of /dev/hwrng, hw_random is
> >the appropriate place for it. It's not a devicetree blob, mac address,
> >or pci config space. Which are things we feed in once for the heck of
> >it. This is a *continuous* source or questionable quality.
> >
> >I'm seriously considering putting this and timeriomem-rng into a
> >subdirectory under hw_random/, maybe environ/. Anything in there gets
> >quality=0 for default, and *doesn't* contribute to /dev/hwrng.
> >
> >Regardless which path we take, I think we should include 'adc' in the
> >name. I've heard countless times about "Atheros cards come with an rng
> >on board". :-/
>
> If I understand correctly, you want to bind the ADC source to
> /dev/hwrng, and then change rng-tools to set the entropy to zero in
> the ioctl call ? There are two major problems with that approach,
Nope. I want to leverage the hwrng framework to facilitate feeding the
*kernel* entropy pools like all the other hwrngs do currently. The
difference for *environmental* sources is that when userspace read()s
from /dev/hwrng, they will *not* contribute.
If the environmental sources are the only sources, then no /dev/hwrng
should appear.
> 1) We already tried once before to bind our solution to /dev/hwrng,
> and got so much complaints. The conclusion was that maybe we know that
> the output of /dev/hwrng does not have perfect entropy, but a normal
> user does not know and will misuse it. You mentioned in
> https://www.kernel.org/doc/Documentation/hw_random.txt we have
>
> "This data is NOT CHECKED by any
> fitness tests, and could potentially be bogus (if the
> hardware is faulty or has been tampered with). Data is only
> output if the hardware "has-data" flag is set, but nevertheless
> a security-conscious person would run fitness tests on the
> data before assuming it is truly random."
>
> But this is not enough to convince upstream to switch to /dev/hwrng.
> I think the concern of users misusing the solution is a very valid
> concern.
Agreed.
> 2) If we set the entropy to zero in rng-tools, we cannot tolerate the
> load. Rng-tools is not a timer-based solution. Similar to our
> solution, it is based on
> /proc/sys/kernel/random/write_wakeup_threshold. If we do not increase
> the entropy counter, rng-tools keep writing into the pool, and both
> rng-tools and WiFi chip will be overloaded.
That's why I propose a change to the hwrng framework to permit noise
sources while not wiring them up to feed /dev/hwrng. timeriomem-rng
should have the same problem ath9k-rng does.
Basically, if it wasn't designed to be an rng, it shouldn't be wired up
to /dev/hwrng.
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 [flat|nested] 48+ messages in thread