Proposed change to linux kernel about random numbers

[Jakob Bohm]

On 18/09/2019 20:58, Salz, Rich via openssl-users wrote:
>
> Please take a look at 
> https://lore.kernel.org/lkml/CAHk-=wiGg-G8JFJ=R7qf0B+UtqA_Weouk6v+McmfsLJLRq6AKA@mail.gmail.com/ 
> and consider giving your comments.
>
> TL;DR:  see the comment below.
>
> + * Hacky workaround for the fact that some processes
>
> + * ask for truly secure random numbers and absolutely want
>
> + * to wait for the entropy pool to fill, and others just
>
> + * do "getrandom(0)" to get some ad-hoc random numbers.
>
> + *
>
> + * If you're generating a secure key, you'd better ask for
>
> + * more than 128 bits of randomness. Otherwise it's not
>
> + * really all that secure by definition.
>
> + *
>
> + * We should add a GRND_SECURE flag so that people can state
>
> + * this "I want secure random numbers" explicitly.
>
Well, I guess that comes from library authors suddenly ignoring
proper usage of the original *random* API definitions, as well
as all related compatibility needs.

Until recently, the rules were clear:

1. If a program or library wanted seeding or bits for generating long
   term keys and was willing to wait, it would use /dev/random or (if
   in both running kernel and loaded libc) getrandom(2) with GRND_RANDOM
   (and soon GRND_SECURE).  This includes waiting for the OS to say it
   has actually gathered entropy etc.

2. If a program or library wanted to set up an internal RNG that can
   be reseeded later it would use /dev/urandom or (if in both running
   kernel and loaded libc) getrandom(2) with neither GRND_RANDOM or
   GRND_SECURE, nor waiting for the kernel to estimate having entropy.
   Then reseed later when OS has more entropy, but not so often as to
   keep the system dry.

3. If a multipurpose library or tool (such as OpenSSL and the openssl
   command line tool) uses the random bits in both ways, it needs to
   pass the choice onto the caller, like OpenSSL 1.0.x did with the
   difference between RAND_pseudo_bytes and RAND_bytes.

   For example, a TLS or SSH implementation can use the weaker entropy
   source to start handling incoming calls (with session keys) soon
   after boot, while a tool to set up initial private keys at first
   boot would need to wait for the stronger entropy source (which may
   in fact get initial randomness over such an encrypted early
   connection!).


Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded