Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1383996 > unrolled thread

[RFC][PATCH 0/6] /dev/random - a new approach

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-21 11:30 +0200
    [PATCH 4/6] crypto: LRNG - enable compile Stephan Mueller <smueller@chronox.de> - 2016-04-21 11:30 +0200
    [PATCH 5/6] crypto: LRNG - hook LRNG into interrupt handler Stephan Mueller <smueller@chronox.de> - 2016-04-21 11:30 +0200
    [PATCH 1/6] crypto: DRBG - externalize DRBG functions for LRNG Stephan Mueller <smueller@chronox.de> - 2016-04-21 11:30 +0200
    Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-21 15:10 +0200
    Re: [RFC][PATCH 0/6] /dev/random - a new approach Nikos Mavrogiannopoulos <nmav@gnutls.org> - 2016-04-21 15:10 +0200
      Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-21 17:20 +0200
        Re: [RFC][PATCH 0/6] /dev/random - a new approach Nikos Mavrogiannopoulos <nmav@gnutls.org> - 2016-04-25 10:00 +0200
          Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-25 10:10 +0200
            Re: [RFC][PATCH 0/6] /dev/random - a new approach Nikos Mavrogiannopoulos <nmav@gnutls.org> - 2016-04-25 10:30 +0200
              Re: [RFC][PATCH 0/6] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-04-26 03:20 +0200
    Re: [RFC][PATCH 0/6] /dev/random - a new approach Theodore Ts'o <tytso@mit.edu> - 2016-04-22 05:00 +0200
      Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-22 07:10 +0200
      Re: [RFC][PATCH 0/6] /dev/random - a new approach Sandy Harris <sandyinchina@gmail.com> - 2016-04-22 15:20 +0200
    Re: [RFC][PATCH 0/6] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-04-24 17:30 +0200
      Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-24 19:40 +0200
        Re: [RFC][PATCH 0/6] /dev/random - a new approach Pavel Machek <pavel@ucw.cz> - 2016-04-24 23:30 +0200
          Re: [RFC][PATCH 0/6] /dev/random - a new approach Stephan Mueller <smueller@chronox.de> - 2016-04-25 07:20 +0200

#1383996 — [RFC][PATCH 0/6] /dev/random - a new approach

Hi Herbert, Ted,

The venerable Linux /dev/random served users of cryptographic mechanisms well
for a long time. Its behavior is well understood to deliver entropic data. In
the last years, however, the Linux /dev/random showed signs of age where it has
challenges to cope with modern computing environments ranging from tiny embedded
systems, over new hardware resources such as SSDs, up to massive parallel
systems as well as virtualized environments.

With the experience gained during numerous studies of /dev/random, entropy
assessments of different noise source designs and assessing entropy behavior in
virtual machines and other special environments, I felt to do something about
it.

I developed a different approach, which I call Linux Random Number Generator
(LRNG) to collect entropy within the Linux kernel. The main improvements
compared to the legacy /dev/random is to provide sufficient entropy during boot
time as well as in virtual environments and when using SSDs. A secondary design
goal is to limit the impact of the entropy collection on massive parallel
systems and also allow the use accelerated cryptographic primitives. Also, all
steps of the entropic data processing are testable. Finally massive performance
improvements are visible at /dev/urandom / get_random_bytes.

The design and implementation is driven by a set of goals described in [1]
that the LRNG completely implements. Furthermore, [1] includes a
comparison with RNG design suggestions such as SP800-90B, SP800-90C, and
AIS20/31.

Please find in [1] the full design discussion covering qualitative assessments
of the entropy collection and entropy flow. Furthermore, a full testing of the
data collection and data processing is performed. The testing focuses on the
calculation of different types of minimum entropy values of raw noise data.
All used test code and supportive tools are provided with [2]. The testing
is concluded with a comparison to the legacy /dev/random implementation
regarding performance and delivery time of entropic random data.

To support a proper review of the code without interfering with the current
functionality, the attached patch adds the LRNG to the cryptodev-2.6 tree as
an option. The patches do not replace or even alter the legacy /dev/random
implementation but allows the user to enable the LRNG at compile time. If it is
enabled, the legacy /dev/random implementation is not compiled. On the other
hand, if the LRNG support is disabled, the legacy /dev/random code is
compiled unchanged. With this approach you see that the LRNG is API and ABI
compatible with the legacy implementation.

Stability tests were executed on 64 and 32 bit systems where the test KVM with 4
vCPUs on 4 hyperthreads compiled the Linux kernel with make -j4 over and over
for half a day. In addition, parallel cat /dev/urandom > /dev/null were
exercised for a couple of hours. Also, stability tests by generating 500
million interrupts were performed.

[1] http://www.chronox.de/lrng/doc/lrng.pdf

[2] http://www.chronox.de/lrng.html

Stephan Mueller (6):
  crypto: DRBG - externalize DRBG functions for LRNG
  random: conditionally compile code depending on LRNG
  crypto: Linux Random Number Generator
  crypto: LRNG - enable compile
  crypto: LRNG - hook LRNG into interrupt handler
  hyperv IRQ handler: trigger LRNG

 crypto/Kconfig         |   10 +
 crypto/Makefile        |    1 +
 crypto/drbg.c          |   11 +-
 crypto/lrng.c          | 1803 ++++++++++++++++++++++++++++++++++++++++++++++++
 drivers/char/random.c  |    8 +
 drivers/hv/vmbus_drv.c |    3 +
 include/crypto/drbg.h  |    7 +
 include/linux/genhd.h  |    5 +
 include/linux/random.h |    8 +
 kernel/irq/handle.c    |    1 +
 10 files changed, 1851 insertions(+), 6 deletions(-)
 create mode 100644 crypto/lrng.c

-- 
2.5.5

,

Ciao
Stephan

[toc] | [next] | [standalone]

#1383998 — [PATCH 4/6] crypto: LRNG - enable compile

Add LRNG compilation support.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/Kconfig  | 10 ++++++++++
 crypto/Makefile |  1 +
 2 files changed, 11 insertions(+)

diff --git a/crypto/Kconfig b/crypto/Kconfig
index 93a1fdc..938f2dc 100644
--- a/crypto/Kconfig
+++ b/crypto/Kconfig
@@ -1587,6 +1587,16 @@ config CRYPTO_JITTERENTROPY
 	  random numbers. This Jitterentropy RNG registers with
 	  the kernel crypto API and can be used by any caller.
 
+config CRYPTO_LRNG
+	bool "Linux Random Number Generator"
+	select CRYPTO_DRBG_MENU
+	help
+	  The Linux Random Number Generator (LRNG) is the replacement
+	  of the legacy /dev/random provided with drivers/char/random.c.
+	  It generates entropy from different noise sources and
+	  delivers significant entropy during boot. The LRNG only
+	  works with the presence of a high-resolution timer.
+
 config CRYPTO_USER_API
 	tristate
 
diff --git a/crypto/Makefile b/crypto/Makefile
index 4f4ef7e..7f91c8e 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -114,6 +114,7 @@ obj-$(CONFIG_CRYPTO_DRBG) += drbg.o
 obj-$(CONFIG_CRYPTO_JITTERENTROPY) += jitterentropy_rng.o
 CFLAGS_jitterentropy.o = -O0
 jitterentropy_rng-y := jitterentropy.o jitterentropy-kcapi.o
+obj-$(CONFIG_CRYPTO_LRNG) += lrng.o
 obj-$(CONFIG_CRYPTO_TEST) += tcrypt.o
 obj-$(CONFIG_CRYPTO_GHASH) += ghash-generic.o
 obj-$(CONFIG_CRYPTO_USER_API) += af_alg.o
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1383999 — [PATCH 5/6] crypto: LRNG - hook LRNG into interrupt handler

The LRNG places a callback into the interrupt handler to be triggered
for each interrupt. With this callback, entropy is collected.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 kernel/irq/handle.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index a15b548..8d64e37 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -175,6 +175,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
 	}
 
 	add_interrupt_randomness(irq, flags);
+	lrng_irq_process();
 
 	if (!noirqdebug)
 		note_interrupt(desc, retval);
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1384003 — [PATCH 1/6] crypto: DRBG - externalize DRBG functions for LRNG

This patch allows several DRBG functions to be called by the LRNG kernel
code paths outside the drbg.c file.

Signed-off-by: Stephan Mueller <smueller@chronox.de>
---
 crypto/drbg.c         | 11 +++++------
 include/crypto/drbg.h |  7 +++++++
 2 files changed, 12 insertions(+), 6 deletions(-)

diff --git a/crypto/drbg.c b/crypto/drbg.c
index 0a3538f..c339a2e 100644
--- a/crypto/drbg.c
+++ b/crypto/drbg.c
@@ -113,7 +113,7 @@
  * the SHA256 / AES 256 over other ciphers. Thus, the favored
  * DRBGs are the latest entries in this array.
  */
-static const struct drbg_core drbg_cores[] = {
+struct drbg_core drbg_cores[] = {
 #ifdef CONFIG_CRYPTO_DRBG_CTR
 	{
 		.flags = DRBG_CTR | DRBG_STRENGTH128,
@@ -205,7 +205,7 @@ static int drbg_uninstantiate(struct drbg_state *drbg);
  * Return: normalized strength in *bytes* value or 32 as default
  *	   to counter programming errors
  */
-static inline unsigned short drbg_sec_strength(drbg_flag_t flags)
+unsigned short drbg_sec_strength(drbg_flag_t flags)
 {
 	switch (flags & DRBG_STRENGTH_MASK) {
 	case DRBG_STRENGTH128:
@@ -1140,7 +1140,7 @@ static int drbg_seed(struct drbg_state *drbg, struct drbg_string *pers,
 }
 
 /* Free all substructures in a DRBG state without the DRBG state structure */
-static inline void drbg_dealloc_state(struct drbg_state *drbg)
+void drbg_dealloc_state(struct drbg_state *drbg)
 {
 	if (!drbg)
 		return;
@@ -1159,7 +1159,7 @@ static inline void drbg_dealloc_state(struct drbg_state *drbg)
  * Allocate all sub-structures for a DRBG state.
  * The DRBG state structure must already be allocated.
  */
-static inline int drbg_alloc_state(struct drbg_state *drbg)
+int drbg_alloc_state(struct drbg_state *drbg)
 {
 	int ret = -ENOMEM;
 	unsigned int sb_size = 0;
@@ -1682,8 +1682,7 @@ static int drbg_kcapi_sym(struct drbg_state *drbg, const unsigned char *key,
  *
  * return: flags
  */
-static inline void drbg_convert_tfm_core(const char *cra_driver_name,
-					 int *coreref, bool *pr)
+void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref, bool *pr)
 {
 	int i = 0;
 	size_t start = 0;
diff --git a/include/crypto/drbg.h b/include/crypto/drbg.h
index d961b2b..d24ec22 100644
--- a/include/crypto/drbg.h
+++ b/include/crypto/drbg.h
@@ -268,4 +268,11 @@ enum drbg_prefixes {
 	DRBG_PREFIX3
 };
 
+extern int drbg_alloc_state(struct drbg_state *drbg);
+extern void drbg_dealloc_state(struct drbg_state *drbg);
+extern void drbg_convert_tfm_core(const char *cra_driver_name, int *coreref,
+				  bool *pr);
+extern struct drbg_core drbg_cores[];
+extern unsigned short drbg_sec_strength(drbg_flag_t flags);
+
 #endif /* _DRBG_H */
-- 
2.5.5

[toc] | [prev] | [next] | [standalone]

#1384187

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos:

Hi Nikos,

> On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller <smueller@chronox.de> 
wrote:
> > Hi Herbert, Ted,
> > 
> > The venerable Linux /dev/random served users of cryptographic mechanisms
> > well for a long time. Its behavior is well understood to deliver entropic
> > data. In the last years, however, the Linux /dev/random showed signs of
> > age where it has challenges to cope with modern computing environments
> > ranging from tiny embedded systems, over new hardware resources such as
> > SSDs, up to massive parallel systems as well as virtualized environments.
> > 
> > With the experience gained during numerous studies of /dev/random, entropy
> > assessments of different noise source designs and assessing entropy
> > behavior in virtual machines and other special environments, I felt to do
> > something about it.
> > I developed a different approach, which I call Linux Random Number
> > Generator (LRNG) to collect entropy within the Linux kernel. The main
> > improvements compared to the legacy /dev/random is to provide sufficient
> > entropy during boot time as well as in virtual environments and when
> > using SSDs. A secondary design goal is to limit the impact of the entropy
> > collection on massive parallel systems and also allow the use accelerated
> > cryptographic primitives. Also, all steps of the entropic data processing
> > are testable. Finally massive performance improvements are visible at
> > /dev/urandom / get_random_bytes.
> 
> [quote from pdf]
> 
> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
> > This is commonly achieved even before user space is initiated.
> 
> Unfortunately one of the issues of the /dev/urandom interface is the
> fact that it may start providing random numbers even before the
> seeding is complete. From the above quote, I understand that this
> issue is not addressed by the new interface. That's a serious
> limitation (of the current and inherited by the new implementation),
> since most/all newly deployed systems from "cloud" images generate
> keys using /dev/urandom (for sshd for example) on boot, and it is
> unknown to these applications whether they operate with uninitialized
> seed.

That limitation is addressed with the getrandom system call. This call will 
block until the initial seeding is provided. After the initial seeding, 
getrandom behaves like /dev/urandom. This behavior is implemented alredy with 
the legacy /dev/random and is preserved with the LRNG.
> 
> While one could argue for using /dev/random, the unpredictability of
> the delay it incurs is prohibitive for any practical use. Thus I'd
> expect any new interface to provide a better /dev/urandom, by ensuring
> that the kernel seed buffer is fully seeded prior to switching to
> userspace.
> 
> About the rest of the design, I think it is quite clean. I think the
> DRBG choice is quite natural given the NIST recommendations, but have
> you considered using a stream cipher instead like chacha20 which in
> most of cases it would outperform the DRBG based on AES?

This can easily be covered by changing the DRBG implementation -- the current 
DRBG implementation in the kernel crypto API is implemented to operate like a 
"block chaining mode" on top of the raw cipher. Thus, such change can be 
easily rolled in.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1384192

On Thu, Apr 21, 2016 at 11:11 AM, Stephan Mueller <smueller@chronox.de> wrote:
> Hi Herbert, Ted,
>
> The venerable Linux /dev/random served users of cryptographic mechanisms well
> for a long time. Its behavior is well understood to deliver entropic data. In
> the last years, however, the Linux /dev/random showed signs of age where it has
> challenges to cope with modern computing environments ranging from tiny embedded
> systems, over new hardware resources such as SSDs, up to massive parallel
> systems as well as virtualized environments.
>
> With the experience gained during numerous studies of /dev/random, entropy
> assessments of different noise source designs and assessing entropy behavior in
> virtual machines and other special environments, I felt to do something about
> it.
> I developed a different approach, which I call Linux Random Number Generator
> (LRNG) to collect entropy within the Linux kernel. The main improvements
> compared to the legacy /dev/random is to provide sufficient entropy during boot
> time as well as in virtual environments and when using SSDs. A secondary design
> goal is to limit the impact of the entropy collection on massive parallel
> systems and also allow the use accelerated cryptographic primitives. Also, all
> steps of the entropic data processing are testable. Finally massive performance
> improvements are visible at /dev/urandom / get_random_bytes.

[quote from pdf]
> ... DRBG is “minimally” seeded with 112^6 bits of entropy.
> This is commonly achieved even before user space is initiated.

Unfortunately one of the issues of the /dev/urandom interface is the
fact that it may start providing random numbers even before the
seeding is complete. From the above quote, I understand that this
issue is not addressed by the new interface. That's a serious
limitation (of the current and inherited by the new implementation),
since most/all newly deployed systems from "cloud" images generate
keys using /dev/urandom (for sshd for example) on boot, and it is
unknown to these applications whether they operate with uninitialized
seed.

While one could argue for using /dev/random, the unpredictability of
the delay it incurs is prohibitive for any practical use. Thus I'd
expect any new interface to provide a better /dev/urandom, by ensuring
that the kernel seed buffer is fully seeded prior to switching to
userspace.

About the rest of the design, I think it is quite clean. I think the
DRBG choice is quite natural given the NIST recommendations, but have
you considered using a stream cipher instead like chacha20 which in
most of cases it would outperform the DRBG based on AES?

regards,
Nikos

[toc] | [prev] | [next] | [standalone]

#1384353

Am Donnerstag, 21. April 2016, 15:03:37 schrieb Nikos Mavrogiannopoulos:

Hi Nikos,
> 
> [quote from pdf]
> 
> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
> > This is commonly achieved even before user space is initiated.
> 
> Unfortunately one of the issues of the /dev/urandom interface is the
> fact that it may start providing random numbers even before the
> seeding is complete. From the above quote, I understand that this
> issue is not addressed by the new interface. That's a serious
> limitation (of the current and inherited by the new implementation),
> since most/all newly deployed systems from "cloud" images generate
> keys using /dev/urandom (for sshd for example) on boot, and it is
> unknown to these applications whether they operate with uninitialized
> seed.

One more item to consider: If you do not want to change to use getrandom(2), 
the LRNG provides you with another means. You may use the 
/proc/sys/kernel/random/drbg_minimally_seeded or drbg_fully_seeded booleans. 
If you poll on those, you will obtain the indication whether the secondary 
DRBG feeding /dev/random is seeded with 112 bits (drbg_minimally_seeded or 256 
bits (drbg_fully_seeded).

Those two booleans are exported for exactly that purpose: allow user space to 
know about initial seeding status of the LRNG.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1386075

On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller <smueller@chronox.de> wrote:
>> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
>> > This is commonly achieved even before user space is initiated.
>>
>> Unfortunately one of the issues of the /dev/urandom interface is the
>> fact that it may start providing random numbers even before the
>> seeding is complete. From the above quote, I understand that this
>> issue is not addressed by the new interface. That's a serious
>> limitation (of the current and inherited by the new implementation),
>> since most/all newly deployed systems from "cloud" images generate
>> keys using /dev/urandom (for sshd for example) on boot, and it is
>> unknown to these applications whether they operate with uninitialized
>> seed.
> One more item to consider: If you do not want to change to use getrandom(2),
> the LRNG provides you with another means.

The main problem is not about willing to switch to getrandom() or not,
but finding any system where getrandom() exists. Today due to libc not
having the call, we can only use /dev/urandom and applications would
most likely continue to do so long time after getrandom() is
introduced to libc.

regards,
Nikos

[toc] | [prev] | [next] | [standalone]

#1386086

Am Montag, 25. April 2016, 09:55:14 schrieb Nikos Mavrogiannopoulos:

Hi Nikos,

> On Thu, Apr 21, 2016 at 5:16 PM, Stephan Mueller <smueller@chronox.de> 
wrote:
> >> > ... DRBG is “minimally” seeded with 112^6 bits of entropy.
> >> > This is commonly achieved even before user space is initiated.
> >> 
> >> Unfortunately one of the issues of the /dev/urandom interface is the
> >> fact that it may start providing random numbers even before the
> >> seeding is complete. From the above quote, I understand that this
> >> issue is not addressed by the new interface. That's a serious
> >> limitation (of the current and inherited by the new implementation),
> >> since most/all newly deployed systems from "cloud" images generate
> >> keys using /dev/urandom (for sshd for example) on boot, and it is
> >> unknown to these applications whether they operate with uninitialized
> >> seed.
> > 
> > One more item to consider: If you do not want to change to use
> > getrandom(2), the LRNG provides you with another means.
> 
> The main problem is not about willing to switch to getrandom() or not,
> but finding any system where getrandom() exists. Today due to libc not
> having the call, we can only use /dev/urandom and applications would
> most likely continue to do so long time after getrandom() is
> introduced to libc.

Implement the syscall yourself with syscall(). If you get ENOSYS back, revert 
to your old logic of seeding from /dev/urandom.

If you know you are on kernels >= 3.14, you could use the following steps in 
your library:

- poll /proc/sys/kernel/random/entropy_avail in spaces of, say, one second and 
block your seeding process until that value becomes non-zero

- if you unblock, seed from /dev/urandom and you have the guarantee of having 
a /dev/urandom seeded with 128 bits.
> 
> regards,
> Nikos


Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1386096

On Mon, Apr 25, 2016 at 10:02 AM, Stephan Mueller <smueller@chronox.de> wrote:
>> > One more item to consider: If you do not want to change to use
>> > getrandom(2), the LRNG provides you with another means.
>> The main problem is not about willing to switch to getrandom() or not,
>> but finding any system where getrandom() exists. Today due to libc not
>> having the call, we can only use /dev/urandom and applications would
>> most likely continue to do so long time after getrandom() is
>> introduced to libc.
> Implement the syscall yourself with syscall(). If you get ENOSYS back, revert
> to your old logic of seeding from /dev/urandom.

That's far from a solution and I wouldn't recommend to anyone doing
that. We cannot expect each and every program to do glibc's job. The
purpose of a system call like getrandom is to simplify the complex use
of /dev/urandom and eliminate it, not to make code handling randomness
in applications even worse.

regards,
Nikos

[toc] | [prev] | [next] | [standalone]

#1387051

On Mon, Apr 25, 2016 at 10:23:51AM +0200, Nikos Mavrogiannopoulos wrote:
> That's far from a solution and I wouldn't recommend to anyone doing
> that. We cannot expect each and every program to do glibc's job. The
> purpose of a system call like getrandom is to simplify the complex use
> of /dev/urandom and eliminate it, not to make code handling randomness
> in applications even worse.

Yes, but if glibc is falling down on the job and refusing to export
the system call (I think for political reasons; it's a Linux-only
interface, so Hurd wouldn't have it), then the only solution is to
either use syscall directly (it's not hard for getrandom, since we're
not using 64-bit arguments which gets tricky for some architectures),
or as Peter Avin has suggested, maybe kernel developers will have to
start releasing the libinux library, and then teaching application
authors to add -linux to their linker lines.

						- Ted

[toc] | [prev] | [next] | [standalone]

#1384671

I still have a massive problem with the claims that the "Jitter" RNG
provides any amount of entropy.  Just because you and I might not be
able to analyze it doesn't mean that somebody else couldn't.  After
all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
be something like

   AES(NSA_KEY, COUNTER++)

Very hard to analyze indeed.  Shall we run statistical tests?  They'll
pass with flying colors.

Secure?  Not so much.

					- Ted

[toc] | [prev] | [next] | [standalone]

#1384694

Am Donnerstag, 21. April 2016, 22:51:55 schrieb Theodore Ts'o:

Hi Theodore,

> I still have a massive problem with the claims that the "Jitter" RNG
> provides any amount of entropy.  Just because you and I might not be
> able to analyze it doesn't mean that somebody else couldn't.  After
> all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
> be something like
> 
>    AES(NSA_KEY, COUNTER++)
> 
> Very hard to analyze indeed.  Shall we run statistical tests?  They'll
> pass with flying colors.
> 
> Secure?  Not so much.

If you are concerned with that RNG, we can easily drop it from the LRNG. The 
testing documented in the writeup disable the Jitter RNG to ensure that only 
the LRNG IRQ collection is tested.

The conclusions regarding timeliness of the seeding, the prevention of 
draining the entropy pool are performed without the Jitter RNG which implies 
that the Jitter RNG can be dropped without harm.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1385161

On Thu, Apr 21, 2016 at 10:51 PM, Theodore Ts'o <tytso@mit.edu> wrote:

> I still have a massive problem with the claims that the "Jitter" RNG
> provides any amount of entropy.  Just because you and I might not be
> able to analyze it doesn't mean that somebody else couldn't.  After
> all, DUAL-EC DRNG was very complicated and hard to analyze.  So would
> be something like
>
>    AES(NSA_KEY, COUNTER++)
>
> Very hard to analyze indeed.  Shall we run statistical tests?  They'll
> pass with flying colors.
>
> Secure?  Not so much.
>
>                                         - Ted

Jitter, havege and my maxwell(8) all claim to get entropy from
variations in timing of simple calculations, and the docs for
all three give arguments that there really is some entropy
there.

Some of those arguments are quite strong. Mine are in
the PDF at:
https://github.com/sandy-harris/maxwell

I find any of those plausible as an external RNG feeding
random(4), though a hardware RNG or Turbid is preferable.

[toc] | [prev] | [next] | [standalone]

#1385823

Hi!

> Please find in [1] the full design discussion covering qualitative assessments
> of the entropy collection and entropy flow. Furthermore, a full
> testing of the

I don't get it.

# The
# idea is that only after obtaining LRNG_POOL_SIZE_BITS healthy bits,
# the
#entropy pool is completely changed with new bits. Yet, the stuck bit
# is not
# discarded as it may still contain some entropy. Hence, it is simply
# XORed
# with the previous bit as the XOR operation maintains the entropy since
# the previous time stamp and the current time stamp are not dependent
# on each other.

So you are relying on high-resolution timestamps. Ok. then you do kind
of the check on the timestamps... ok, why not. But then you mix in the
data regardless, saying that "they are not dependent" and thus can't
hurt.

But you already know they _are_ dependent, that's what your stuck test
told you:

# Thus, the stuck test
# ensures that:
# (a) variations exist in the time deltas,
# (b) variations of time deltas do not have a simple repeating pattern,
# and
# (c) variations do not have a linearly changing patterns (e.g. 1 - 2 -
# 4 - 7
# - 11 - 16).


Now. I could imagine cases where interrupts are correlated... like
some hardware may generate two interrupts for each event or something
like that...

What goes on if high resolution timer is not available?

Best regards,
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1385850

Am Sonntag, 24. April 2016, 17:21:09 schrieb Pavel Machek:

Hi Pavel,

> Hi!
> 
> > Please find in [1] the full design discussion covering qualitative
> > assessments of the entropy collection and entropy flow. Furthermore, a
> > full
> > testing of the
> 
> I don't get it.
> 
> # The
> # idea is that only after obtaining LRNG_POOL_SIZE_BITS healthy bits,
> # the
> #entropy pool is completely changed with new bits. Yet, the stuck bit
> # is not
> # discarded as it may still contain some entropy. Hence, it is simply
> # XORed
> # with the previous bit as the XOR operation maintains the entropy since
> # the previous time stamp and the current time stamp are not dependent
> # on each other.
> 
> So you are relying on high-resolution timestamps. Ok. then you do kind
> of the check on the timestamps... ok, why not. But then you mix in the
> data regardless, saying that "they are not dependent" and thus can't
> hurt.
> 
> But you already know they _are_ dependent, that's what your stuck test
> told you:

The stuck test says that there is a pattern, but not that the pattern shows a 
dependency.
> 
> # Thus, the stuck test
> # ensures that:
> # (a) variations exist in the time deltas,
> # (b) variations of time deltas do not have a simple repeating pattern,
> # and
> # (c) variations do not have a linearly changing patterns (e.g. 1 - 2 -
> # 4 - 7
> # - 11 - 16).
> 
> 
> Now. I could imagine cases where interrupts are correlated... like
> some hardware may generate two interrupts for each event or something
> like that...

But I see what you are referring to and I think you have a valid point in a 
worst case assessment.

Thus, any stuck value should not be mixed into the pool.

I have changed the code accordingly.

> 
> What goes on if high resolution timer is not available?

See lrng_init:

/* This RNG does not work if no high-resolution timer is available */
BUG_ON(!random_get_entropy() && !random_get_entropy());

If there is no high-resolution timer, the LRNG will not produce good entropic 
random numbers. The current kernel code implements high-resolution timers for 
all but the following architectures where neither random_get_entropy nor 
get_cycles are implemented:

- AVR32

- CRIS

- FR-V

- H8300

- Hexagon

- M32R

- METAG

- Microblaze

- SPARC 32

- Score

- SH

- UM

- Unicore32

- Xtensa

Thus, for all large-scale architectures, the LRNG would be applicable.

Please note that also the legacy /dev/random will have hard time to obtain 
entropy for these environments. The majority of the entropy comes from high-
resolution time stamps. If you do not have them and you rely on Jiffies, an 
attacker has the ability to predict the events mixed into the pools with a 
high accuracy. Please remember the outcry when MIPS was identified to have no 
get_cycles about two or three years back.

Though, the patch I offer leaves the legacy /dev/random in peace for those 
architectures to not touch the status quo.

Ciao
Stephan

[toc] | [prev] | [next] | [standalone]

#1385927

Hi!

> > So you are relying on high-resolution timestamps. Ok. then you do kind
> > of the check on the timestamps... ok, why not. But then you mix in the
> > data regardless, saying that "they are not dependent" and thus can't
> > hurt.
> > 
> > But you already know they _are_ dependent, that's what your stuck test
> > told you:
> 
> The stuck test says that there is a pattern, but not that the pattern shows a 
> dependency.
...
> > Now. I could imagine cases where interrupts are correlated... like
> > some hardware may generate two interrupts for each event or something
> > like that...
> 
> But I see what you are referring to and I think you have a valid point in a 
> worst case assessment.
> 
> Thus, any stuck value should not be mixed into the pool.

Thanks.

> /* This RNG does not work if no high-resolution timer is available */
> BUG_ON(!random_get_entropy() && !random_get_entropy());

Heh, does this cause BUG() with 2^-64 probability? :-).

> If there is no high-resolution timer, the LRNG will not produce good entropic 
> random numbers. The current kernel code implements high-resolution timers for 
> all but the following architectures where neither random_get_entropy nor 
> get_cycles are implemented:

Ok, what about stuff like Intel 486 (no RDTSC)?

> Thus, for all large-scale architectures, the LRNG would be applicable.
> 
> Please note that also the legacy /dev/random will have hard time to obtain 
> entropy for these environments. The majority of the entropy comes
> from high-

Understood.

> Though, the patch I offer leaves the legacy /dev/random in peace for those 
> architectures to not touch the status quo.

Well -- that's the major problem -- right? Makes it tricky to tell
what changed, and we had two RNGs to maintain.

Best regards,
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[toc] | [prev] | [next] | [standalone]

#1386012

Am Sonntag, 24. April 2016, 23:25:00 schrieb Pavel Machek:

Hi Pavel,

> > /* This RNG does not work if no high-resolution timer is available */
> > BUG_ON(!random_get_entropy() && !random_get_entropy());
> 
> Heh, does this cause BUG() with 2^-64 probability? :-).

No, but for the listed arches, get_cycles would return 0. And I only call the 
function twice to not be tripped by a potential wrap around at the time of 
calling.
> 
> > If there is no high-resolution timer, the LRNG will not produce good
> > entropic random numbers. The current kernel code implements
> > high-resolution timers for all but the following architectures where
> > neither random_get_entropy nor
> > get_cycles are implemented:
> Ok, what about stuff like Intel 486 (no RDTSC)?
> 
> > Thus, for all large-scale architectures, the LRNG would be applicable.
> > 
> > Please note that also the legacy /dev/random will have hard time to obtain
> > entropy for these environments. The majority of the entropy comes
> > from high-
> 
> Understood.
> 
> > Though, the patch I offer leaves the legacy /dev/random in peace for those
> > architectures to not touch the status quo.
> 
> Well -- that's the major problem -- right? Makes it tricky to tell
> what changed, and we had two RNGs to maintain.

I would rather think that even the legacy /dev/random should not return any 
values in those environments. The random numbers that are returned on these 
systems are bogus, considering that the only noise source that could deliver 
some entropy excluding timestamps (if you trust the user) are the HID event 
values. And for those listed systems, I doubt very much that they are used in 
a desktop environment where you have a console.

If everybody agrees, I can surely add some logic to make the LRNG working on 
those systems. But those additions cannot be subjected to a thorough entropy 
analysis. Yet I feel that this is wrong.

My goal with the LRNG is to provide a new design using proven techniques that 
is forward looking. I am aware that the design does not work in circumstances 
where the high-res timer is not present. But do we have to settle on the least 
common denominator knowing that this one will not really work to begin with?

Ciao
Stephan

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web