[openssl-users] RNG behavior by default

[Steffen Nurpmeso]

Good evening.

Jakob Bohm via openssl-users wrote in <95bceb59-b299-015a-f9c2-e2487a699\
8ad at wisemo.com>:
 |Small corrections below:
 |
 |On 07/01/2019 19:31, Steffen Nurpmeso wrote:
 |
 ||...
 |||RAND_load_file() and all this stuff. Just make sure the os entropy \
 |||sources
 |||are available and then simply use RAND_bytes(). But don't expect it to
 |||succeed always.
 |
 ||And may i ask, what to do if it fails?  Try it in a loop a finite
 ||number of times, assuming it over-and-over detects it is in an
 ||error state and tries to reseed unless that succeeds, and bail if
 ||still without success thereafter?
 |
 ||Talking about the only program in the public that i represent:
 ||i will not abort that one just because a PRNG fails to produce
 ||some bytes that this program uses for the purpose of, well, having
 ||some (pseudo but) random bytes; because: this is _completely_
 ||disproportionate to the use cases of those random numbers.
 ||I guess the same could be said about UUIDS generated via PRNGs
 ||instead of how the standard defines them, etc. etc.
 ||Please do not say "use random(3) or rand(3)" now, please.
 ||So what to do?
 |
 |"Just failing" is precisely to allow you (and others) to do something 
 |sensible without the random bytes, such as using something less secure, 
 |or doing a polite error reporting to the user.

I have to say i struggle with the OpenSSL project release
announcements.  Really.  I see a short mail which simply points
users to some (granted super duper) web site (with custom fonts
and such -- it must look fantastic on such a tablet thing that
i do not own!), and on these pages, which i, unfortunately and
until now, over and over again look at, ... to see nothing.

I mean, OpenSSL is such a vivid part of the infrastructure, top
that with security, of the world, it is used a billion of times
each and every day, and how many people really now about the
details inside this library with the terrible interface names (a
few minutes ago i discovered the also new ADMISSIONS.pod
documentation, and this is a statement for a language with
namespaces and method-on-object not instance-on-function; i always
think by myself that some university should perform neurological
science on what looking at

  const STACK_OF(ADMISSIONS) *ADMISSION_SYNTAX_get0_contentsOfAdmissions(const ADMISSION_SYNTAX *as);

from 9 to 5 (or 14 to 04 or whatever)/365-52 actually causes, how
do you say that in english?, what damages to the brain it causes,
anyway.)

The thing is, i have just seen the release candidate announcement
for bash 5.0 a while ago, and know what my own release message
will (have to) look like.

I did know nothing of all that.

 |||> I think i will move away from RAND_ then, nonetheless, and at
 |||> least for the things i have control of.
 |||
 |||I don't think this is a good idea. In the case when there is no suitable \
 |||\
 |||entropy
 |||source, the OpenSSL RNG will fail to generate random bytes, indeed.
 |||But how do you expect your application to seed the RNG properly in this
 |||case? What is your application's entropy source? If you have one, which
 |
 ||Yes, that is the problem.  We do have several possibilities for
 ||VAL_RANDOM.  Some of them only seed our builtin ARC4
 ||implementation, which until now exposes the internal buffer as
 ...
 ||randomizing those weakly through the well-known algorithm from
 ||"Random number generators: good ones are hard to find", Park and
 ||Miller, Communications of the ACM, vol. 31, no. 10, October 1988,
 ||p. 1195 (a_aux_rand_weak()).  This is the code:
 ...
 |Note that since that ancient article, ARC4 was not only invented, 
 |but also found too insecure for modern use.

I seem to know that for things like save transport.
I have for example suppressed adding the 

   for(u.i = 5 * sizeof(a_aux_rand->b8); u.i != 0; --u.i)
      a_aux_rand_get8();

which follows the unscientific seeding.  (And which likely is also
unscientific given that we have been seeded with random data
rather than with key/nonce ... whatever.)

 |Enjoy

Not really!  For example i read

  The reseeding default values are applied only during creation of
  a DRBG instance.  To ensure that they are applied to the global
  and thread-local DRBG instances (<master>, resp. <public> and
  <private>), it is necessary to call
  RAND_DRBG_set_reseed_defaults() before creating any thread and
  before calling any cryptographic routines that obtain random
  data directly or indirectly.

Does this give me at least the promise that OPENSSL_init_ssl() can
be called without rendering RAND_DRBG_set_reseed_defaults(0,0,0,0)
effectively a useless call?
I see that said function may return error, but it seems that the
MAX_RESEED_INTERVAL it fails to accept is not a public variable!
I tend to do the much more expensive dance with
RAND_DRBG_get0_public() and RAND_DRBG_get0_master() and
individually applying RAND_DRBG_set_reseed_time_interval() as well
as RAND_DRBG_set_reseed_interval() on each of them.
Is this even allowed without calling OPENSSL_init_ssl() first?

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)