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@xxxxxxxxxxxxxx/
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
