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


Groups > linux.kernel > #1386012

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

From Stephan Mueller <smueller@chronox.de>
Newsgroups linux.kernel
Subject Re: [RFC][PATCH 0/6] /dev/random - a new approach
Date 2016-04-25 07:20 +0200
Message-ID <rrH6a-kh-19@gated-at.bofh.it> (permalink)
References <rqj5U-6Uw-13@gated-at.bofh.it> <rrwaK-8jH-15@gated-at.bofh.it> <rrzLl-2IO-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


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

Back to linux.kernel | Previous | NextPrevious in thread | Find similar | Unroll thread


Thread

[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

csiph-web