Make the threshold at which the output entropy pools are considered to
be initialized configurable via a kernel command line option. The
current integer value of 128 bits is a good default value. However, some
user groups may want to use different values. For example, the SOGIS
group now requires 125 bits at least (BSI, the participant at that group
used to require 100 bits). NIST moved from 80 bits to 112 bits starting
with 2014.
It is therefore to be expected that in the future, this threshold may
increase for different user groups.
CC: Ted Tso <[email protected]>
Signed-off-by: Stephan Mueller <[email protected]>
---
Documentation/kernel-parameters.txt | 7 +++++++
drivers/char/random.c | 26 +++++++++++++++++++++++++-
2 files changed, 32 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt
index 61ab162..bc6c6f1 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2965,6 +2965,13 @@ bytes respectively. Such letter suffixes can also be entirely omitted.
ramdisk_size= [RAM] Sizes of RAM disks in kilobytes
See Documentation/blockdev/ramdisk.txt.
+ random_initialized= [KNL] Set the threshold in bits at which the
+ Linux random number generator considers an output
+ entropy pool initialized.
+ Format: <int> (must be >= 112 and <= size of output
+ entropy pool in bits)
+ Default: 128
+
rcu_nocbs= [KNL]
In kernels built with CONFIG_RCU_NOCB_CPU=y, set
the specified list of CPUs to be no-callback CPUs.
diff --git a/drivers/char/random.c b/drivers/char/random.c
index 9cd6968..cfe4d9b 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -317,6 +317,12 @@ static int random_write_wakeup_bits = 28 * OUTPUT_POOL_WORDS;
static int random_min_urandom_seed = 60;
/*
+ * Threshold of entropy at which an entropy pool is considered to be
+ * initialized.
+ */
+static int random_initialized_threshold = 128;
+
+/*
* Originally, we used a primitive polynomial of degree .poolwords
* over GF(2). The taps for various sizes are defined below. They
* were chosen to be evenly spaced except for the last tap, which is 1
@@ -655,7 +661,8 @@ retry:
goto retry;
r->entropy_total += nbits;
- if (!r->initialized && r->entropy_total > 128) {
+ if (!r->initialized &&
+ r->entropy_total > random_initialized_threshold) {
r->initialized = 1;
r->entropy_total = 0;
if (r == &nonblocking_pool) {
@@ -938,6 +945,23 @@ void add_disk_randomness(struct gendisk *disk)
EXPORT_SYMBOL_GPL(add_disk_randomness);
#endif
+/* Process kernel command-line parameter at boot time. */
+static __init int random_initalized_cmdline(char *str)
+{
+ unsigned long thresh = simple_strtoul(str, NULL, 10);
+
+ if (thresh < 112)
+ thresh = 112;
+ if (thresh > OUTPUT_POOL_WORDS * 32)
+ thresh = OUTPUT_POOL_WORDS * 32;
+ random_initialized_threshold = thresh;
+ pr_notice("random: entropy pool initialization threshold set to %d bits\n",
+ random_initialized_threshold);
+ return 1;
+}
+
+__setup("random_initialized=", random_initalized_cmdline);
+
/*********************************************************************
*
* Entropy extraction routines
--
2.1.0
On Mon, May 18, 2015 at 06:25:25PM +0200, Stephan Mueller wrote:
> Make the threshold at which the output entropy pools are considered to
> be initialized configurable via a kernel command line option. The
> current integer value of 128 bits is a good default value. However, some
> user groups may want to use different values. For example, the SOGIS
> group now requires 125 bits at least (BSI, the participant at that group
> used to require 100 bits). NIST moved from 80 bits to 112 bits starting
> with 2014.
>
> It is therefore to be expected that in the future, this threshold may
> increase for different user groups.
>
> CC: Ted Tso <[email protected]>
> Signed-off-by: Stephan Mueller <[email protected]>
How much does 125 vs 112 vs 128 bits really matter? Is the cost of
waiting the extra 16 bits (the difference between 112 and 128 bits)
really that high? I'm not entirely convincd that adding Yet Another
Tuning parameter is really worth it. If we stick with 128 bits, we
will satisfy SOGIS, BSI, NIST, etc., and I would find it difficult to
believe that someone would want 132, 147, etc., bits.
- Ted
Am Montag, 18. Mai 2015, 14:42:09 schrieb Theodore Ts'o:
Hi Theodore,
>On Mon, May 18, 2015 at 06:25:25PM +0200, Stephan Mueller wrote:
>> Make the threshold at which the output entropy pools are considered to
>> be initialized configurable via a kernel command line option. The
>> current integer value of 128 bits is a good default value. However, some
>> user groups may want to use different values. For example, the SOGIS
>> group now requires 125 bits at least (BSI, the participant at that group
>> used to require 100 bits). NIST moved from 80 bits to 112 bits starting
>> with 2014.
>>
>> It is therefore to be expected that in the future, this threshold may
>> increase for different user groups.
>>
>> CC: Ted Tso <[email protected]>
>> Signed-off-by: Stephan Mueller <[email protected]>
>
>How much does 125 vs 112 vs 128 bits really matter? Is the cost of
>waiting the extra 16 bits (the difference between 112 and 128 bits)
>really that high? I'm not entirely convincd that adding Yet Another
>Tuning parameter is really worth it. If we stick with 128 bits, we
>will satisfy SOGIS, BSI, NIST, etc., and I would find it difficult to
>believe that someone would want 132, 147, etc., bits.
I hear more and more discussions about recommendations to use AES 256 and not
AES 128.
These kind of recommendations will eventually also affect the entropy
requirements for noise sources. This is my motivation for the patch: allowing
different user groups to set the minimum bar for the nonblocking pool to
*higher* levels (the examples for 80 to 112 bits or 100 to 125 bits shall just
show that there are active revisions of entropy requirements).
Ciao
Stephan
Stephan Mueller <[email protected]> wrote:
>
> I hear more and more discussions about recommendations to use AES 256 and not
> AES 128.
>
> These kind of recommendations will eventually also affect the entropy
> requirements for noise sources. This is my motivation for the patch: allowing
> different user groups to set the minimum bar for the nonblocking pool to
> *higher* levels (the examples for 80 to 112 bits or 100 to 125 bits shall just
> show that there are active revisions of entropy requirements).
Does anyone need to raise this from 128 today? If not then this
patch is pointless.
--
Email: Herbert Xu <[email protected]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, May 18, 2015 at 6:58 PM, Herbert Xu <[email protected]> wrote:
> Stephan Mueller <[email protected]> wrote:
>>
>> I hear more and more discussions about recommendations to use AES 256 and not
>> AES 128.
Or perhaps other ciphers with 256-bit keys. Salsa, ChaCha and several of
the Caesar candidates support those.
>> These kind of recommendations will eventually also affect the entropy
>> requirements for noise sources. This is my motivation for the patch: allowing
>> different user groups to set the minimum bar for the nonblocking pool to
>> *higher* levels (the examples for 80 to 112 bits or 100 to 125 bits shall just
>> show that there are active revisions of entropy requirements).
>
> Does anyone need to raise this from 128 today? If not then this
> patch is pointless.
There is an RFC for ChaCha in IETF protocols
https://www.rfc-editor.org/rfc/rfc7539.txt
That RFC is new, issued this month, so it will probably be a while
before we need to worry about it.
I do think finding a way to support changing the init requirement from
128 to 256 bits will be useful at some point. However, I doubt it is
urgent since few protocols need it now. On the other hand, IPsec and
TLS both include AES-256, I think.
When we do do it, I see no reason to support anything other than 128
and 256, and I am not sure about retaining 128. Nor do I see any
reason this should be a command-line option rather than just a
compile-time constant.
Am Dienstag, 19. Mai 2015, 18:40:20 schrieb Sandy Harris:
Hi Sandy,
>
>When we do do it, I see no reason to support anything other than 128
>and 256, and I am not sure about retaining 128. Nor do I see any
>reason this should be a command-line option rather than just a
>compile-time constant.
I would hazard to guess that a compile time option is a bit difficult for
distributions which typically only want one kernel for all their user base. As
that user base is typically large, they would potentially be unable to please
everybody with a compile time option.
But I see that such a change may not be warranted at this point. Though, I see
that discussion may rise again in the future when such new requirements for
256 bit keys (not only AES, thanks Sandy for mentioning :-) ) are commonly
raised.
So, let us disregard the patch until hard requirements are coming up.
Ciao
Stephan
On Wed, May 20, 2015 at 08:29:19AM +0200, Stephan Mueller wrote:
>
> But I see that such a change may not be warranted at this
> point. Though, I see that discussion may rise again in the future
> when such new requirements for 256 bit keys (not only AES, thanks
> Sandy for mentioning :-) ) are commonly raised.
Given that you would need a 15,360-bit RSA key to have a key strength
equivalent to a 256-bit key (and a 3072-bit RSA key is equivalent to
128-bit symmetric keys, and there are plenty of people still using
2048-bit keys), permit me to be a little skeptical about the value of
256 bit keys for anything other than marketing value...
If you trust ECC, you'd "only" need a 7,680 bit ECC key. But the ECC
curves under discussion today are (at least) an order of magnitude
smaller.
And if it's just to make gullible rubes feel safer, I don't see the
real point of non-blocking random pool threshold larger than the
safety of the whole system is constrainted by public key crypto.
> So, let us disregard the patch until hard requirements are coming up.
Sounds like a fine idea to me.
- Ted
Am Mittwoch, 20. Mai 2015, 11:06:42 schrieb Theodore Ts'o:
Hi Theodore,
As a side note to this discussion, may I ask why entropy_total is used for
checking against the threshold value and not entropy_count?
The reason for my question is the following: until a DRNG (in the worst case,
nonblocking_pool is a DRNG) is fully seeded, partial seeds may be "eaten" up
by the caller.
For the discussion, let us assume the worst case that there is coming in one
bit of entropy at a time. In between the addition of each bit of entropy, an
attacker can access the DRNG (i.e. the SHA1 output of the nonblocking_pool).
When only one bit of entropy is added to the nonblocking_pool, the attack
complexity would be 1 bit. When an attacker would access the nonblocking_pool
after each received bit, in the worst case, the attack complexity is not
2**128 but rather 256 (i.e. 1 bit for each individual attack between the
addition of one new bit of entropy).
So, the total attack complexity is the sum of the individual attack
complexities (i.e. the complexity added after the previous attack is
performed).
When using the entropy_count variable which is affected by account() (i.e. it
is decreased when a reader obtains data), the threshold is only reached when
truly 128 unobserved bits are collected.
Ciao
Stephan
On Mon 2015-05-18 18:25:25, Stephan Mueller wrote:
> Make the threshold at which the output entropy pools are considered to
> be initialized configurable via a kernel command line option. The
> current integer value of 128 bits is a good default value. However, some
> user groups may want to use different values. For example, the SOGIS
> group now requires 125 bits at least (BSI, the participant at that group
> used to require 100 bits). NIST moved from 80 bits to 112 bits starting
> with 2014.
>
> It is therefore to be expected that in the future, this threshold may
> increase for different user groups.
Speaking of random and kernel parameters... should we add random=<hex
digits> parameter to pass entropy from bootloader to the kernel?
u-boot-SPL does DRAM calibration, for example, and I guess that may
provide some rather hard to guess values...
[I initialy misread parameter below as "random_initize=" and thought
it does exactly this...]
Pavel
> + random_initialized= [KNL] Set the threshold in bits at which the
> + Linux random number generator considers an output
> + entropy pool initialized.
> + Format: <int> (must be >= 112 and <= size of output
> + entropy pool in bits)
> + Default: 128
> +
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek:
Hi Pavel,
> On Mon 2015-05-18 18:25:25, Stephan Mueller wrote:
> > Make the threshold at which the output entropy pools are considered to
> > be initialized configurable via a kernel command line option. The
> > current integer value of 128 bits is a good default value. However, some
> > user groups may want to use different values. For example, the SOGIS
> > group now requires 125 bits at least (BSI, the participant at that group
> > used to require 100 bits). NIST moved from 80 bits to 112 bits starting
> > with 2014.
> >
> > It is therefore to be expected that in the future, this threshold may
> > increase for different user groups.
>
> Speaking of random and kernel parameters... should we add random=<hex
> digits> parameter to pass entropy from bootloader to the kernel?
Everybody can see that string. How do you think that way of providing entropy
is protected?
> u-boot-SPL does DRAM calibration, for example, and I guess that may
> provide some rather hard to guess values...
>
> [I initialy misread parameter below as "random_initize=" and thought
> it does exactly this...]
> Pavel
>
> > + random_initialized= [KNL] Set the threshold in bits at which the
> > + Linux random number generator considers an output
> > + entropy pool initialized.
> > + Format: <int> (must be >= 112 and <= size of output
> > + entropy pool in bits)
> > + Default: 128
> > +
--
Ciao
Stephan
On Tue 2015-06-23 23:47:33, Stephan Mueller wrote:
> Am Dienstag, 23. Juni 2015, 22:44:11 schrieb Pavel Machek:
>
> Hi Pavel,
>
> > On Mon 2015-05-18 18:25:25, Stephan Mueller wrote:
> > > Make the threshold at which the output entropy pools are considered to
> > > be initialized configurable via a kernel command line option. The
> > > current integer value of 128 bits is a good default value. However, some
> > > user groups may want to use different values. For example, the SOGIS
> > > group now requires 125 bits at least (BSI, the participant at that group
> > > used to require 100 bits). NIST moved from 80 bits to 112 bits starting
> > > with 2014.
> > >
> > > It is therefore to be expected that in the future, this threshold may
> > > increase for different user groups.
> >
> > Speaking of random and kernel parameters... should we add random=<hex
> > digits> parameter to pass entropy from bootloader to the kernel?
>
> Everybody can see that string. How do you think that way of providing entropy
> is protected?
Only local users, not remote attackers. And yes, we should probably
"censor" the command line for this use.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html