From: Miaoqing Pan <[email protected]>
The quality of ADC entropy is 10 bits of min-entropy for
a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
'(((x) * 8 * 10) >> 5)' for easier understanding.
Signed-off-by: Miaoqing Pan <[email protected]>
---
drivers/net/wireless/ath/ath9k/rng.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/rng.c b/drivers/net/wireless/ath/ath9k/rng.c
index d38e50f..568b1c6 100644
--- a/drivers/net/wireless/ath/ath9k/rng.c
+++ b/drivers/net/wireless/ath/ath9k/rng.c
@@ -22,7 +22,7 @@
#include "ar9003_phy.h"
#define ATH9K_RNG_BUF_SIZE 320
-#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 320) >> 10) /* quality: 320/1024 */
+#define ATH9K_RNG_ENTROPY(x) (((x) * 8 * 10) >> 5) /* quality: 10/32 */
static int ath9k_rng_data_read(struct ath_softc *sc, u32 *buf, u32 buf_size)
{
--
1.9.1
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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
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
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb [email protected]:
Hi Miaoqing,
> From: Miaoqing Pan <[email protected]>
>
> 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 <[email protected]>
As a short term solution:
Acked-by: Stephan Mueller <[email protected]>
But as Jason outlined, there should be nothing that prevents using this code
with the HW Random framework. This framework also has logic to limit the rate
of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
> config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
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
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 <[email protected]>
Sent: Tuesday, August 9, 2016 5:37 PM
To: Herbert Xu
Cc: Pan, Miaoqing; Matt Mackall; [email protected]; Valo, Kalle; [email protected]; ath9k-devel; [email protected]; [email protected]; 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
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
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/[email protected]
and top of thread:
https://lkml.kernel.org/r/[email protected]
thx,
Jason.
From: Miaoqing Pan <[email protected]>
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 <[email protected]>
---
drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/Kconfig b/drivers/net/wireless/ath/ath9k/Kconfig
index f68cb00..8f231c6 100644
--- a/drivers/net/wireless/ath/ath9k/Kconfig
+++ b/drivers/net/wireless/ath/ath9k/Kconfig
@@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS
config ATH9K_HWRNG
bool "Random number generator support"
depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
- default y
+ default n
---help---
This option incorporates the ADC register output as a source of
randomness into Linux entropy pool (/dev/urandom and /dev/random)
--
1.9.1
On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
>
> Herbert, Matt, should such noise sources be added to the HW random framework?
> The thing is that the in-kernel HW random to input_pool link per default uses
> a more conservative entropy estimate than the user space rngd. I would think
> that the in-kernel link would appropriate for that rng. But the user space
> rngd tool with its default behavior is not really suited here.
Yes hwrng would be the best fit, with a quality of zero to be safe.
Contrary to the quoted thread, there is no need to whiten the output
/dev/hw_random. It was always meant to go through some intermediate
processing such as rngd before it is used.
Cheers,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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.
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
Am Dienstag, 9. August 2016, 16:58:58 CEST schrieb Herbert Xu:
Hi Herbert,
> On Tue, Aug 09, 2016 at 10:07:29AM +0200, Stephan Mueller wrote:
> > Herbert, Matt, should such noise sources be added to the HW random
> > framework? The thing is that the in-kernel HW random to input_pool link
> > per default uses a more conservative entropy estimate than the user space
> > rngd. I would think that the in-kernel link would appropriate for that
> > rng. But the user space rngd tool with its default behavior is not really
> > suited here.
>
> Yes hwrng would be the best fit, with a quality of zero to be safe.
>
> Contrary to the quoted thread, there is no need to whiten the output
> /dev/hw_random. It was always meant to go through some intermediate
> processing such as rngd before it is used.
But shouldn't the default of the rngd then be adjusted a bit?
>
> Cheers,
Ciao
Stephan
On Tue, Aug 09, 2016 at 11:02:58AM +0200, Stephan Mueller wrote:
>
> But shouldn't the default of the rngd then be adjusted a bit?
Please elaborate.
Thanks,
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
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:[email protected]]
Sent: Wednesday, August 10, 2016 1:29 PM
To: Pan, Miaoqing <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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
Am Dienstag, 9. August 2016, 07:35:33 CEST schrieb Pan, Miaoqing:
Hi Miaoqing, Herbert, Matt,
> Hi Stephan,
>
> So your suggestion is to use HW Random framework ? Actually, which was
> done by the commit 6301566e0b2d ("ath9k: export HW random number
> generator"), but it was reverted, you can refer to
> https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html
> for more information.
I see, it is the same RNG we talked about earlier. The issue is that the
suggested rngd per default assumes one bit of entropy with every data bit.
This is not given with this noise source. This is the basis of my reply last
time.
Herbert, Matt, should such noise sources be added to the HW random framework?
The thing is that the in-kernel HW random to input_pool link per default uses
a more conservative entropy estimate than the user space rngd. I would think
that the in-kernel link would appropriate for that rng. But the user space
rngd tool with its default behavior is not really suited here.
Thanks
Stephan
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
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
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 <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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:[email protected]]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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
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
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 <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Tue, Aug 09, 2016 at 03:02:27PM +0800, [email protected] wrote:
> From: Miaoqing Pan <[email protected]>
>
> 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 <[email protected]>
Until we get the hw_random/get_device_randomness question sorted...
Reviewed-by: Jason Cooper <[email protected]>
thx,
Jason.
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:[email protected]]
Sent: Wednesday, August 10, 2016 2:25 PM
To: Pan, Miaoqing <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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
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
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:[email protected]]
Sent: Wednesday, August 10, 2016 3:27 PM
To: Pan, Miaoqing <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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
Hi Stephan,
So your suggestion is to use HW Random framework ? Actually, which was done by the commit 6301566e0b2d ("ath9k: export HW random number generator"), but it was reverted, you can refer to https://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg15483.html for more information.
--
Miaoqing
-----Original Message-----
From: Stephan Mueller [mailto:[email protected]]
Sent: Tuesday, August 09, 2016 3:15 PM
To: [email protected]
Cc: Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
Subject: Re: [PATCH 2/2] ath9k: disable RNG by default
Am Dienstag, 9. August 2016, 15:02:27 CEST schrieb [email protected]:
Hi Miaoqing,
> From: Miaoqing Pan <[email protected]>
>
> 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 <[email protected]>
As a short term solution:
Acked-by: Stephan Mueller <[email protected]>
But as Jason outlined, there should be nothing that prevents using this code with the HW Random framework. This framework also has logic to limit the rate of injection and allows the setting of the entropy threshold at runtime.
> ---
> drivers/net/wireless/ath/ath9k/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/ath/ath9k/Kconfig
> b/drivers/net/wireless/ath/ath9k/Kconfig index f68cb00..8f231c6 100644
> --- a/drivers/net/wireless/ath/ath9k/Kconfig
> +++ b/drivers/net/wireless/ath/ath9k/Kconfig
> @@ -180,7 +180,7 @@ config ATH9K_HTC_DEBUGFS config ATH9K_HWRNG
> bool "Random number generator support"
> depends on ATH9K && (HW_RANDOM = y || HW_RANDOM = ATH9K)
> - default y
> + default n
> ---help---
> This option incorporates the ADC register output as a source of
> randomness into Linux entropy pool (/dev/urandom and /dev/random)
Ciao
Stephan
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:[email protected]]
Sent: Wednesday, August 10, 2016 2:52 PM
To: Pan, Miaoqing <[email protected]>
Cc: Herbert Xu <[email protected]>; Matt Mackall <[email protected]>; [email protected]; Valo, Kalle <[email protected]>; [email protected]; ath9k-devel <[email protected]>; [email protected]; [email protected]; Sepehrdad, Pouyan <[email protected]>
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
On Thu, Aug 11, 2016 at 10:54:11AM +0800, [email protected] 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.
miaoqing pan <[email protected]> wrote:
> From: Miaoqing Pan <[email protected]>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <[email protected]>
I need some help here, it this patch ok to take or should I drop it? The
discussion is available from the patchwork link below if someone needs to
refresh the memory.
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
miaoqing pan <[email protected]> wrote:
> From: Miaoqing Pan <[email protected]>
>
> 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 <[email protected]>
> Acked-by: Stephan Mueller <[email protected]>
> Acked-by: Stephan Mueller <[email protected]>
> Reviewed-by: Jason Cooper <[email protected]>
Patch applied to ath-next branch of ath.git, thanks.
739ccd76b40e ath9k: disable RNG by default
--
https://patchwork.kernel.org/patch/9270467/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
miaoqing pan <[email protected]> wrote:
> From: Miaoqing Pan <[email protected]>
>
> The quality of ADC entropy is 10 bits of min-entropy for
> a 32-bit value, change '(((x) * 8 * 320) >> 10)' to
> '(((x) * 8 * 10) >> 5)' for easier understanding.
>
> Signed-off-by: Miaoqing Pan <[email protected]>
Patch applied to ath-next branch of ath.git, thanks.
e463139a7262 ath9k: change entropy formula for easier understanding
--
https://patchwork.kernel.org/patch/9270463/
Documentation about submitting wireless patches and checking status
from patchwork:
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches