2006-10-17 09:09:42 +02:00
|
|
|
/*
|
2014-04-03 23:49:08 +02:00
|
|
|
* This is a maximally equidistributed combined Tausworthe generator
|
|
|
|
|
* based on code from GNU Scientific Library 1.5 (30 Jun 2004)
|
|
|
|
|
*
|
|
|
|
|
* lfsr113 version:
|
|
|
|
|
*
|
|
|
|
|
* x_n = (s1_n ^ s2_n ^ s3_n ^ s4_n)
|
|
|
|
|
*
|
|
|
|
|
* s1_{n+1} = (((s1_n & 4294967294) << 18) ^ (((s1_n << 6) ^ s1_n) >> 13))
|
|
|
|
|
* s2_{n+1} = (((s2_n & 4294967288) << 2) ^ (((s2_n << 2) ^ s2_n) >> 27))
|
|
|
|
|
* s3_{n+1} = (((s3_n & 4294967280) << 7) ^ (((s3_n << 13) ^ s3_n) >> 21))
|
|
|
|
|
* s4_{n+1} = (((s4_n & 4294967168) << 13) ^ (((s4_n << 3) ^ s4_n) >> 12))
|
|
|
|
|
*
|
|
|
|
|
* The period of this generator is about 2^113 (see erratum paper).
|
|
|
|
|
*
|
|
|
|
|
* From: P. L'Ecuyer, "Maximally Equidistributed Combined Tausworthe
|
|
|
|
|
* Generators", Mathematics of Computation, 65, 213 (1996), 203--213:
|
|
|
|
|
* http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
|
|
|
|
|
* ftp://ftp.iro.umontreal.ca/pub/simulation/lecuyer/papers/tausme.ps
|
|
|
|
|
*
|
|
|
|
|
* There is an erratum in the paper "Tables of Maximally Equidistributed
|
|
|
|
|
* Combined LFSR Generators", Mathematics of Computation, 68, 225 (1999),
|
|
|
|
|
* 261--269: http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
|
|
|
|
|
*
|
|
|
|
|
* ... the k_j most significant bits of z_j must be non-zero,
|
|
|
|
|
* for each j. (Note: this restriction also applies to the
|
|
|
|
|
* computer code given in [4], but was mistakenly not mentioned
|
|
|
|
|
* in that paper.)
|
|
|
|
|
*
|
|
|
|
|
* This affects the seeding procedure by imposing the requirement
|
|
|
|
|
* s1 > 1, s2 > 7, s3 > 15, s4 > 127.
|
|
|
|
|
*/
|
2006-10-17 09:09:42 +02:00
|
|
|
|
|
|
|
|
#include <linux/types.h>
|
|
|
|
|
#include <linux/percpu.h>
|
2011-11-17 03:29:17 +01:00
|
|
|
#include <linux/export.h>
|
2006-10-18 07:47:25 +02:00
|
|
|
#include <linux/jiffies.h>
|
2006-10-17 09:09:42 +02:00
|
|
|
#include <linux/random.h>
|
2013-11-11 12:20:37 +01:00
|
|
|
#include <linux/sched.h>
|
|
|
|
|
|
|
|
|
|
#ifdef CONFIG_RANDOM32_SELFTEST
|
|
|
|
|
static void __init prandom_state_selftest(void);
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
#else
|
|
|
|
|
static inline void prandom_state_selftest(void)
|
|
|
|
|
{
|
|
|
|
|
}
|
2013-11-11 12:20:37 +01:00
|
|
|
#endif
|
2006-10-17 09:09:42 +02:00
|
|
|
|
|
|
|
|
static DEFINE_PER_CPU(struct rnd_state, net_rand_state);
|
|
|
|
|
|
2010-05-26 23:44:13 +02:00
|
|
|
/**
|
2012-12-18 01:04:23 +01:00
|
|
|
* prandom_u32_state - seeded pseudo-random number generator.
|
2010-05-26 23:44:13 +02:00
|
|
|
* @state: pointer to state structure holding seeded state.
|
|
|
|
|
*
|
|
|
|
|
* This is used for pseudo-randomness with no outside seeding.
|
2012-12-18 01:04:23 +01:00
|
|
|
* For more random results, use prandom_u32().
|
2010-05-26 23:44:13 +02:00
|
|
|
*/
|
2012-12-18 01:04:23 +01:00
|
|
|
u32 prandom_u32_state(struct rnd_state *state)
|
2006-10-17 09:09:42 +02:00
|
|
|
{
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
#define TAUSWORTHE(s, a, b, c, d) ((s & c) << d) ^ (((s << a) ^ s) >> b)
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
state->s1 = TAUSWORTHE(state->s1, 6U, 13U, 4294967294U, 18U);
|
|
|
|
|
state->s2 = TAUSWORTHE(state->s2, 2U, 27U, 4294967288U, 2U);
|
|
|
|
|
state->s3 = TAUSWORTHE(state->s3, 13U, 21U, 4294967280U, 7U);
|
|
|
|
|
state->s4 = TAUSWORTHE(state->s4, 3U, 12U, 4294967168U, 13U);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
return (state->s1 ^ state->s2 ^ state->s3 ^ state->s4);
|
2006-10-17 09:09:42 +02:00
|
|
|
}
|
2012-12-18 01:04:23 +01:00
|
|
|
EXPORT_SYMBOL(prandom_u32_state);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
|
|
|
|
/**
|
2012-12-18 01:04:23 +01:00
|
|
|
* prandom_u32 - pseudo random number generator
|
2006-10-17 09:09:42 +02:00
|
|
|
*
|
|
|
|
|
* A 32 bit pseudo-random number is generated using a fast
|
|
|
|
|
* algorithm suitable for simulation. This algorithm is NOT
|
|
|
|
|
* considered safe for cryptographic use.
|
|
|
|
|
*/
|
2012-12-18 01:04:23 +01:00
|
|
|
u32 prandom_u32(void)
|
2006-10-17 09:09:42 +02:00
|
|
|
{
|
|
|
|
|
struct rnd_state *state = &get_cpu_var(net_rand_state);
|
2014-04-03 23:49:08 +02:00
|
|
|
u32 res;
|
|
|
|
|
|
|
|
|
|
res = prandom_u32_state(state);
|
2006-10-17 09:09:42 +02:00
|
|
|
put_cpu_var(state);
|
2014-04-03 23:49:08 +02:00
|
|
|
|
|
|
|
|
return res;
|
2006-10-17 09:09:42 +02:00
|
|
|
}
|
2012-12-18 01:04:23 +01:00
|
|
|
EXPORT_SYMBOL(prandom_u32);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
2014-04-03 23:49:08 +02:00
|
|
|
/**
|
2012-12-18 01:04:25 +01:00
|
|
|
* prandom_bytes_state - get the requested number of pseudo-random bytes
|
|
|
|
|
*
|
|
|
|
|
* @state: pointer to state structure holding seeded state.
|
|
|
|
|
* @buf: where to copy the pseudo-random bytes to
|
|
|
|
|
* @bytes: the requested number of bytes
|
|
|
|
|
*
|
|
|
|
|
* This is used for pseudo-randomness with no outside seeding.
|
|
|
|
|
* For more random results, use prandom_bytes().
|
|
|
|
|
*/
|
|
|
|
|
void prandom_bytes_state(struct rnd_state *state, void *buf, int bytes)
|
|
|
|
|
{
|
|
|
|
|
unsigned char *p = buf;
|
|
|
|
|
int i;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < round_down(bytes, sizeof(u32)); i += sizeof(u32)) {
|
|
|
|
|
u32 random = prandom_u32_state(state);
|
|
|
|
|
int j;
|
|
|
|
|
|
|
|
|
|
for (j = 0; j < sizeof(u32); j++) {
|
|
|
|
|
p[i + j] = random;
|
|
|
|
|
random >>= BITS_PER_BYTE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
if (i < bytes) {
|
|
|
|
|
u32 random = prandom_u32_state(state);
|
|
|
|
|
|
|
|
|
|
for (; i < bytes; i++) {
|
|
|
|
|
p[i] = random;
|
|
|
|
|
random >>= BITS_PER_BYTE;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(prandom_bytes_state);
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* prandom_bytes - get the requested number of pseudo-random bytes
|
|
|
|
|
* @buf: where to copy the pseudo-random bytes to
|
|
|
|
|
* @bytes: the requested number of bytes
|
|
|
|
|
*/
|
|
|
|
|
void prandom_bytes(void *buf, int bytes)
|
|
|
|
|
{
|
|
|
|
|
struct rnd_state *state = &get_cpu_var(net_rand_state);
|
|
|
|
|
|
|
|
|
|
prandom_bytes_state(state, buf, bytes);
|
|
|
|
|
put_cpu_var(state);
|
|
|
|
|
}
|
|
|
|
|
EXPORT_SYMBOL(prandom_bytes);
|
|
|
|
|
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
static void prandom_warmup(struct rnd_state *state)
|
|
|
|
|
{
|
|
|
|
|
/* Calling RNG ten times to satify recurrence condition */
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
prandom_u32_state(state);
|
|
|
|
|
}
|
|
|
|
|
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
static u32 __extract_hwseed(void)
|
2013-11-11 12:20:37 +01:00
|
|
|
{
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
u32 val = 0;
|
|
|
|
|
|
|
|
|
|
(void)(arch_get_random_seed_int(&val) ||
|
|
|
|
|
arch_get_random_int(&val));
|
|
|
|
|
|
|
|
|
|
return val;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static void prandom_seed_early(struct rnd_state *state, u32 seed,
|
|
|
|
|
bool mix_with_hwseed)
|
|
|
|
|
{
|
|
|
|
|
#define LCG(x) ((x) * 69069U) /* super-duper LCG */
|
|
|
|
|
#define HWSEED() (mix_with_hwseed ? __extract_hwseed() : 0)
|
|
|
|
|
state->s1 = __seed(HWSEED() ^ LCG(seed), 2U);
|
|
|
|
|
state->s2 = __seed(HWSEED() ^ LCG(state->s1), 8U);
|
|
|
|
|
state->s3 = __seed(HWSEED() ^ LCG(state->s2), 16U);
|
|
|
|
|
state->s4 = __seed(HWSEED() ^ LCG(state->s3), 128U);
|
2013-11-11 12:20:37 +01:00
|
|
|
}
|
|
|
|
|
|
2006-10-17 09:09:42 +02:00
|
|
|
/**
|
2012-12-18 01:04:23 +01:00
|
|
|
* prandom_seed - add entropy to pseudo random number generator
|
2006-10-17 09:09:42 +02:00
|
|
|
* @seed: seed value
|
|
|
|
|
*
|
2012-12-18 01:04:23 +01:00
|
|
|
* Add some additional seeding to the prandom pool.
|
2006-10-17 09:09:42 +02:00
|
|
|
*/
|
2012-12-18 01:04:23 +01:00
|
|
|
void prandom_seed(u32 entropy)
|
2006-10-17 09:09:42 +02:00
|
|
|
{
|
2008-04-03 23:07:02 +02:00
|
|
|
int i;
|
|
|
|
|
/*
|
|
|
|
|
* No locking on the CPUs, but then somewhat random results are, well,
|
|
|
|
|
* expected.
|
|
|
|
|
*/
|
|
|
|
|
for_each_possible_cpu (i) {
|
|
|
|
|
struct rnd_state *state = &per_cpu(net_rand_state, i);
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
|
|
|
|
|
state->s1 = __seed(state->s1 ^ entropy, 2U);
|
|
|
|
|
prandom_warmup(state);
|
2008-04-03 23:07:02 +02:00
|
|
|
}
|
2006-10-17 09:09:42 +02:00
|
|
|
}
|
2012-12-18 01:04:23 +01:00
|
|
|
EXPORT_SYMBOL(prandom_seed);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Generate some initially weak seeding values to allow
|
2012-12-18 01:04:23 +01:00
|
|
|
* to start the prandom_u32() engine.
|
2006-10-17 09:09:42 +02:00
|
|
|
*/
|
2012-12-18 01:04:23 +01:00
|
|
|
static int __init prandom_init(void)
|
2006-10-17 09:09:42 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
|
|
|
|
|
2013-11-11 12:20:37 +01:00
|
|
|
prandom_state_selftest();
|
|
|
|
|
|
2006-10-17 09:09:42 +02:00
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
|
struct rnd_state *state = &per_cpu(net_rand_state,i);
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
u32 weak_seed = (i + jiffies) ^ random_get_entropy();
|
2008-07-31 01:29:19 +02:00
|
|
|
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
prandom_seed_early(state, weak_seed, true);
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
prandom_warmup(state);
|
2006-10-17 09:09:42 +02:00
|
|
|
}
|
2014-04-03 23:49:08 +02:00
|
|
|
|
2006-10-17 09:09:42 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
2012-12-18 01:04:23 +01:00
|
|
|
core_initcall(prandom_init);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
2013-11-11 12:20:33 +01:00
|
|
|
static void __prandom_timer(unsigned long dontcare);
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
|
2013-11-11 12:20:33 +01:00
|
|
|
static DEFINE_TIMER(seed_timer, __prandom_timer, 0, 0);
|
|
|
|
|
|
|
|
|
|
static void __prandom_timer(unsigned long dontcare)
|
|
|
|
|
{
|
|
|
|
|
u32 entropy;
|
2013-11-12 23:45:42 +01:00
|
|
|
unsigned long expires;
|
2013-11-11 12:20:33 +01:00
|
|
|
|
|
|
|
|
get_random_bytes(&entropy, sizeof(entropy));
|
|
|
|
|
prandom_seed(entropy);
|
2013-11-12 23:45:42 +01:00
|
|
|
|
2013-11-11 12:20:33 +01:00
|
|
|
/* reseed every ~60 seconds, in [40 .. 80) interval with slack */
|
2013-11-12 23:45:42 +01:00
|
|
|
expires = 40 + (prandom_u32() % 40);
|
|
|
|
|
seed_timer.expires = jiffies + msecs_to_jiffies(expires * MSEC_PER_SEC);
|
|
|
|
|
|
2013-11-11 12:20:33 +01:00
|
|
|
add_timer(&seed_timer);
|
|
|
|
|
}
|
|
|
|
|
|
2013-11-12 23:45:41 +01:00
|
|
|
static void __init __prandom_start_seed_timer(void)
|
2013-11-11 12:20:33 +01:00
|
|
|
{
|
|
|
|
|
set_timer_slack(&seed_timer, HZ);
|
2013-11-12 23:45:42 +01:00
|
|
|
seed_timer.expires = jiffies + msecs_to_jiffies(40 * MSEC_PER_SEC);
|
2013-11-11 12:20:33 +01:00
|
|
|
add_timer(&seed_timer);
|
|
|
|
|
}
|
|
|
|
|
|
2006-10-17 09:09:42 +02:00
|
|
|
/*
|
|
|
|
|
* Generate better values after random number generator
|
2010-06-11 12:17:00 +02:00
|
|
|
* is fully initialized.
|
2006-10-17 09:09:42 +02:00
|
|
|
*/
|
2013-11-11 12:20:34 +01:00
|
|
|
static void __prandom_reseed(bool late)
|
2006-10-17 09:09:42 +02:00
|
|
|
{
|
|
|
|
|
int i;
|
2013-11-11 12:20:34 +01:00
|
|
|
unsigned long flags;
|
|
|
|
|
static bool latch = false;
|
|
|
|
|
static DEFINE_SPINLOCK(lock);
|
|
|
|
|
|
2014-03-28 17:38:42 +01:00
|
|
|
/* Asking for random bytes might result in bytes getting
|
|
|
|
|
* moved into the nonblocking pool and thus marking it
|
|
|
|
|
* as initialized. In this case we would double back into
|
|
|
|
|
* this function and attempt to do a late reseed.
|
|
|
|
|
* Ignore the pointless attempt to reseed again if we're
|
|
|
|
|
* already waiting for bytes when the nonblocking pool
|
|
|
|
|
* got initialized.
|
|
|
|
|
*/
|
|
|
|
|
|
2013-11-11 12:20:34 +01:00
|
|
|
/* only allow initial seeding (late == false) once */
|
2014-03-28 17:38:42 +01:00
|
|
|
if (!spin_trylock_irqsave(&lock, flags))
|
|
|
|
|
return;
|
|
|
|
|
|
2013-11-11 12:20:34 +01:00
|
|
|
if (latch && !late)
|
|
|
|
|
goto out;
|
2014-04-03 23:49:08 +02:00
|
|
|
|
2013-11-11 12:20:34 +01:00
|
|
|
latch = true;
|
2006-10-17 09:09:42 +02:00
|
|
|
|
|
|
|
|
for_each_possible_cpu(i) {
|
|
|
|
|
struct rnd_state *state = &per_cpu(net_rand_state,i);
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
u32 seeds[4];
|
2008-07-31 01:29:19 +02:00
|
|
|
|
|
|
|
|
get_random_bytes(&seeds, sizeof(seeds));
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
state->s1 = __seed(seeds[0], 2U);
|
|
|
|
|
state->s2 = __seed(seeds[1], 8U);
|
|
|
|
|
state->s3 = __seed(seeds[2], 16U);
|
|
|
|
|
state->s4 = __seed(seeds[3], 128U);
|
2006-10-17 09:09:42 +02:00
|
|
|
|
random32: upgrade taus88 generator to taus113 from errata paper
Since we use prandom*() functions quite often in networking code
i.e. in UDP port selection, netfilter code, etc, upgrade the PRNG
from Pierre L'Ecuyer's original paper "Maximally Equidistributed
Combined Tausworthe Generators", Mathematics of Computation, 65,
213 (1996), 203--213 to the version published in his errata paper [1].
The Tausworthe generator is a maximally-equidistributed generator,
that is fast and has good statistical properties [1].
The version presented there upgrades the 3 state LFSR to a 4 state
LFSR with increased periodicity from about 2^88 to 2^113. The
algorithm is presented in [1] by the very same author who also
designed the original algorithm in [2].
Also, by increasing the state, we make it a bit harder for attackers
to "guess" the PRNGs internal state. See also discussion in [3].
Now, as we use this sort of weak initialization discussed in [3]
only between core_initcall() until late_initcall() time [*] for
prandom32*() users, namely in prandom_init(), it is less relevant
from late_initcall() onwards as we overwrite seeds through
prandom_reseed() anyways with a seed source of higher entropy, that
is, get_random_bytes(). In other words, a exhaustive keysearch of
96 bit would be needed. Now, with the help of this patch, this
state-search increases further to 128 bit. Initialization needs
to make sure that s1 > 1, s2 > 7, s3 > 15, s4 > 127.
taus88 and taus113 algorithm is also part of GSL. I added a test
case in the next patch to verify internal behaviour of this patch
with GSL and ran tests with the dieharder 3.31.1 RNG test suite:
$ dieharder -g 052 -a -m 10 -s 1 -S 4137730333 #taus88
$ dieharder -g 054 -a -m 10 -s 1 -S 4137730333 #taus113
With this seed configuration, in order to compare both, we get
the following differences:
algorithm taus88 taus113
rands/second [**] 1.61e+08 1.37e+08
sts_serial(4, 1st run) WEAK PASSED
sts_serial(9, 2nd run) WEAK PASSED
rgb_lagged_sum(31) WEAK PASSED
We took out diehard_sums test as according to the authors it is
considered broken and unusable [4]. Despite that and the slight
decrease in performance (which is acceptable), taus113 here passes
all 113 tests (only rgb_minimum_distance_5 in WEAK, the rest PASSED).
In general, taus/taus113 is considered "very good" by the authors
of dieharder [5].
The papers [1][2] states a single warm-up step is sufficient by
running quicktaus once on each state to ensure proper initialization
of ~s_{0}:
Our selection of (s) according to Table 1 of [1] row 1 holds the
condition L - k <= r - s, that is,
(32 32 32 32) - (31 29 28 25) <= (25 27 15 22) - (18 2 7 13)
with r = k - q and q = (6 2 13 3) as also stated by the paper.
So according to [2] we are safe with one round of quicktaus for
initialization. However we decided to include the warm-up phase
of the PRNG as done in GSL in every case as a safety net. We also
use the warm up phase to make the output of the RNG easier to
verify by the GSL output.
In prandom_init(), we also mix random_get_entropy() into it, just
like drivers/char/random.c does it, jiffies ^ random_get_entropy().
random-get_entropy() is get_cycles(). xor is entropy preserving so
it is fine if it is not implemented by some architectures.
Note, this PRNG is *not* used for cryptography in the kernel, but
rather as a fast PRNG for various randomizations i.e. in the
networking code, or elsewhere for debugging purposes, for example.
[*]: In order to generate some "sort of pseduo-randomness", since
get_random_bytes() is not yet available for us, we use jiffies and
initialize states s1 - s3 with a simple linear congruential generator
(LCG), that is x <- x * 69069; and derive s2, s3, from the 32bit
initialization from s1. So the above quote from [3] accounts only
for the time from core to late initcall, not afterwards.
[**] Single threaded run on MacBook Air w/ Intel Core i5-3317U
[1] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme2.ps
[2] http://www.iro.umontreal.ca/~lecuyer/myftp/papers/tausme.ps
[3] http://thread.gmane.org/gmane.comp.encryption.general/12103/
[4] http://code.google.com/p/dieharder/source/browse/trunk/libdieharder/diehard_sums.c?spec=svn490&r=490#20
[5] http://www.phy.duke.edu/~rgb/General/dieharder.php
Joint work with Hannes Frederic Sowa.
Cc: Florian Weimer <fweimer@redhat.com>
Cc: Theodore Ts'o <tytso@mit.edu>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-11-11 12:20:36 +01:00
|
|
|
prandom_warmup(state);
|
2006-10-17 09:09:42 +02:00
|
|
|
}
|
2013-11-11 12:20:34 +01:00
|
|
|
out:
|
|
|
|
|
spin_unlock_irqrestore(&lock, flags);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void prandom_reseed_late(void)
|
|
|
|
|
{
|
|
|
|
|
__prandom_reseed(true);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
static int __init prandom_reseed(void)
|
|
|
|
|
{
|
|
|
|
|
__prandom_reseed(false);
|
2013-11-12 23:45:41 +01:00
|
|
|
__prandom_start_seed_timer();
|
2006-10-17 09:09:42 +02:00
|
|
|
return 0;
|
|
|
|
|
}
|
2012-12-18 01:04:23 +01:00
|
|
|
late_initcall(prandom_reseed);
|
2013-11-11 12:20:37 +01:00
|
|
|
|
|
|
|
|
#ifdef CONFIG_RANDOM32_SELFTEST
|
|
|
|
|
static struct prandom_test1 {
|
|
|
|
|
u32 seed;
|
|
|
|
|
u32 result;
|
|
|
|
|
} test1[] = {
|
|
|
|
|
{ 1U, 3484351685U },
|
|
|
|
|
{ 2U, 2623130059U },
|
|
|
|
|
{ 3U, 3125133893U },
|
|
|
|
|
{ 4U, 984847254U },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static struct prandom_test2 {
|
|
|
|
|
u32 seed;
|
|
|
|
|
u32 iteration;
|
|
|
|
|
u32 result;
|
|
|
|
|
} test2[] = {
|
|
|
|
|
/* Test cases against taus113 from GSL library. */
|
|
|
|
|
{ 931557656U, 959U, 2975593782U },
|
|
|
|
|
{ 1339693295U, 876U, 3887776532U },
|
|
|
|
|
{ 1545556285U, 961U, 1615538833U },
|
|
|
|
|
{ 601730776U, 723U, 1776162651U },
|
|
|
|
|
{ 1027516047U, 687U, 511983079U },
|
|
|
|
|
{ 416526298U, 700U, 916156552U },
|
|
|
|
|
{ 1395522032U, 652U, 2222063676U },
|
|
|
|
|
{ 366221443U, 617U, 2992857763U },
|
|
|
|
|
{ 1539836965U, 714U, 3783265725U },
|
|
|
|
|
{ 556206671U, 994U, 799626459U },
|
|
|
|
|
{ 684907218U, 799U, 367789491U },
|
|
|
|
|
{ 2121230701U, 931U, 2115467001U },
|
|
|
|
|
{ 1668516451U, 644U, 3620590685U },
|
|
|
|
|
{ 768046066U, 883U, 2034077390U },
|
|
|
|
|
{ 1989159136U, 833U, 1195767305U },
|
|
|
|
|
{ 536585145U, 996U, 3577259204U },
|
|
|
|
|
{ 1008129373U, 642U, 1478080776U },
|
|
|
|
|
{ 1740775604U, 939U, 1264980372U },
|
|
|
|
|
{ 1967883163U, 508U, 10734624U },
|
|
|
|
|
{ 1923019697U, 730U, 3821419629U },
|
|
|
|
|
{ 442079932U, 560U, 3440032343U },
|
|
|
|
|
{ 1961302714U, 845U, 841962572U },
|
|
|
|
|
{ 2030205964U, 962U, 1325144227U },
|
|
|
|
|
{ 1160407529U, 507U, 240940858U },
|
|
|
|
|
{ 635482502U, 779U, 4200489746U },
|
|
|
|
|
{ 1252788931U, 699U, 867195434U },
|
|
|
|
|
{ 1961817131U, 719U, 668237657U },
|
|
|
|
|
{ 1071468216U, 983U, 917876630U },
|
|
|
|
|
{ 1281848367U, 932U, 1003100039U },
|
|
|
|
|
{ 582537119U, 780U, 1127273778U },
|
|
|
|
|
{ 1973672777U, 853U, 1071368872U },
|
|
|
|
|
{ 1896756996U, 762U, 1127851055U },
|
|
|
|
|
{ 847917054U, 500U, 1717499075U },
|
|
|
|
|
{ 1240520510U, 951U, 2849576657U },
|
|
|
|
|
{ 1685071682U, 567U, 1961810396U },
|
|
|
|
|
{ 1516232129U, 557U, 3173877U },
|
|
|
|
|
{ 1208118903U, 612U, 1613145022U },
|
|
|
|
|
{ 1817269927U, 693U, 4279122573U },
|
|
|
|
|
{ 1510091701U, 717U, 638191229U },
|
|
|
|
|
{ 365916850U, 807U, 600424314U },
|
|
|
|
|
{ 399324359U, 702U, 1803598116U },
|
|
|
|
|
{ 1318480274U, 779U, 2074237022U },
|
|
|
|
|
{ 697758115U, 840U, 1483639402U },
|
|
|
|
|
{ 1696507773U, 840U, 577415447U },
|
|
|
|
|
{ 2081979121U, 981U, 3041486449U },
|
|
|
|
|
{ 955646687U, 742U, 3846494357U },
|
|
|
|
|
{ 1250683506U, 749U, 836419859U },
|
|
|
|
|
{ 595003102U, 534U, 366794109U },
|
|
|
|
|
{ 47485338U, 558U, 3521120834U },
|
|
|
|
|
{ 619433479U, 610U, 3991783875U },
|
|
|
|
|
{ 704096520U, 518U, 4139493852U },
|
|
|
|
|
{ 1712224984U, 606U, 2393312003U },
|
|
|
|
|
{ 1318233152U, 922U, 3880361134U },
|
|
|
|
|
{ 855572992U, 761U, 1472974787U },
|
|
|
|
|
{ 64721421U, 703U, 683860550U },
|
|
|
|
|
{ 678931758U, 840U, 380616043U },
|
|
|
|
|
{ 692711973U, 778U, 1382361947U },
|
|
|
|
|
{ 677703619U, 530U, 2826914161U },
|
|
|
|
|
{ 92393223U, 586U, 1522128471U },
|
|
|
|
|
{ 1222592920U, 743U, 3466726667U },
|
|
|
|
|
{ 358288986U, 695U, 1091956998U },
|
|
|
|
|
{ 1935056945U, 958U, 514864477U },
|
|
|
|
|
{ 735675993U, 990U, 1294239989U },
|
|
|
|
|
{ 1560089402U, 897U, 2238551287U },
|
|
|
|
|
{ 70616361U, 829U, 22483098U },
|
|
|
|
|
{ 368234700U, 731U, 2913875084U },
|
|
|
|
|
{ 20221190U, 879U, 1564152970U },
|
|
|
|
|
{ 539444654U, 682U, 1835141259U },
|
|
|
|
|
{ 1314987297U, 840U, 1801114136U },
|
|
|
|
|
{ 2019295544U, 645U, 3286438930U },
|
|
|
|
|
{ 469023838U, 716U, 1637918202U },
|
|
|
|
|
{ 1843754496U, 653U, 2562092152U },
|
|
|
|
|
{ 400672036U, 809U, 4264212785U },
|
|
|
|
|
{ 404722249U, 965U, 2704116999U },
|
|
|
|
|
{ 600702209U, 758U, 584979986U },
|
|
|
|
|
{ 519953954U, 667U, 2574436237U },
|
|
|
|
|
{ 1658071126U, 694U, 2214569490U },
|
|
|
|
|
{ 420480037U, 749U, 3430010866U },
|
|
|
|
|
{ 690103647U, 969U, 3700758083U },
|
|
|
|
|
{ 1029424799U, 937U, 3787746841U },
|
|
|
|
|
{ 2012608669U, 506U, 3362628973U },
|
|
|
|
|
{ 1535432887U, 998U, 42610943U },
|
|
|
|
|
{ 1330635533U, 857U, 3040806504U },
|
|
|
|
|
{ 1223800550U, 539U, 3954229517U },
|
|
|
|
|
{ 1322411537U, 680U, 3223250324U },
|
|
|
|
|
{ 1877847898U, 945U, 2915147143U },
|
|
|
|
|
{ 1646356099U, 874U, 965988280U },
|
|
|
|
|
{ 805687536U, 744U, 4032277920U },
|
|
|
|
|
{ 1948093210U, 633U, 1346597684U },
|
|
|
|
|
{ 392609744U, 783U, 1636083295U },
|
|
|
|
|
{ 690241304U, 770U, 1201031298U },
|
|
|
|
|
{ 1360302965U, 696U, 1665394461U },
|
|
|
|
|
{ 1220090946U, 780U, 1316922812U },
|
|
|
|
|
{ 447092251U, 500U, 3438743375U },
|
|
|
|
|
{ 1613868791U, 592U, 828546883U },
|
|
|
|
|
{ 523430951U, 548U, 2552392304U },
|
|
|
|
|
{ 726692899U, 810U, 1656872867U },
|
|
|
|
|
{ 1364340021U, 836U, 3710513486U },
|
|
|
|
|
{ 1986257729U, 931U, 935013962U },
|
|
|
|
|
{ 407983964U, 921U, 728767059U },
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
static void __init prandom_state_selftest(void)
|
|
|
|
|
{
|
|
|
|
|
int i, j, errors = 0, runs = 0;
|
|
|
|
|
bool error = false;
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(test1); i++) {
|
|
|
|
|
struct rnd_state state;
|
|
|
|
|
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
prandom_seed_early(&state, test1[i].seed, false);
|
2013-11-11 12:20:37 +01:00
|
|
|
prandom_warmup(&state);
|
|
|
|
|
|
|
|
|
|
if (test1[i].result != prandom_u32_state(&state))
|
|
|
|
|
error = true;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (error)
|
|
|
|
|
pr_warn("prandom: seed boundary self test failed\n");
|
|
|
|
|
else
|
|
|
|
|
pr_info("prandom: seed boundary self test passed\n");
|
|
|
|
|
|
|
|
|
|
for (i = 0; i < ARRAY_SIZE(test2); i++) {
|
|
|
|
|
struct rnd_state state;
|
|
|
|
|
|
random32: mix in entropy from core to late initcall
Currently, we have a 3-stage seeding process in prandom():
Phase 1 is from the early actual initialization of prandom()
subsystem which happens during core_initcall() and remains
most likely until the beginning of late_initcall() phase.
Here, the system might not have enough entropy available
for seeding with strong randomness from the random driver.
That means, we currently have a 32bit weak LCG() seeding
the PRNG status register 1 and mixing that successively
into the other 3 registers just to get it up and running.
Phase 2 starts with late_initcall() phase resp. when the
random driver has initialized its non-blocking pool with
enough entropy. At that time, we throw away *all* inner
state from its 4 registers and do a full reseed with strong
randomness.
Phase 3 starts right after that and does a periodic reseed
with random slack of status register 1 by a strong random
source again.
A problem in phase 1 is that during bootup data structures
can be initialized, e.g. on module load time, and thus access
a weakly seeded prandom and are never changed for the rest
of their live-time, thus carrying along the results from a
week seed. Lets make sure that current but also future users
access a possibly better early seeded prandom.
This patch therefore improves phase 1 by trying to make it
more 'unpredictable' through mixing in seed from a possible
hardware source. Now, the mix-in xors inner state with the
outcome of either of the two functions arch_get_random_{,seed}_int(),
preferably arch_get_random_seed_int() as it likely represents
a non-deterministic random bit generator in hw rather than
a cryptographically secure PRNG in hw. However, not all might
have the first one, so we use the PRNG as a fallback if
available. As we xor the seed into the current state, the
worst case would be that a hardware source could be unverifiable
compromised or backdoored. In that case nevertheless it
would be as good as our original early seeding function
prandom_seed_very_weak() since we mix through xor which is
entropy preserving.
Joint work with Daniel Borkmann.
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-28 14:01:38 +02:00
|
|
|
prandom_seed_early(&state, test2[i].seed, false);
|
2013-11-11 12:20:37 +01:00
|
|
|
prandom_warmup(&state);
|
|
|
|
|
|
|
|
|
|
for (j = 0; j < test2[i].iteration - 1; j++)
|
|
|
|
|
prandom_u32_state(&state);
|
|
|
|
|
|
|
|
|
|
if (test2[i].result != prandom_u32_state(&state))
|
|
|
|
|
errors++;
|
|
|
|
|
|
|
|
|
|
runs++;
|
|
|
|
|
cond_resched();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if (errors)
|
|
|
|
|
pr_warn("prandom: %d/%d self tests failed\n", errors, runs);
|
|
|
|
|
else
|
|
|
|
|
pr_info("prandom: %d self tests passed\n", runs);
|
|
|
|
|
}
|
|
|
|
|
#endif
|