On Thu, 18 Apr 2019 10:22:27 +0200 Lennart Poettering <mzerqung@xxxxxxxxxxx> wrote: > On Mi, 17.04.19 11:29, Japheth Cleaver (cleaver@xxxxxxxxxxxxxx) wrote: > > This seems like a false dichotomy, no? Surely, things like this are > > a possibility: > > https://lists.freedesktop.org/archives/systemd-devel/2010-September/000225.html > > That too means the service gets started after the init system is up, > and the init system already requires entropy, so it's pointless. On shutdown the existing entropy is stored for use at startup (it is still entropy on restart if an attacker hasn't seen it). So, if init uses that entropy and depletes it, it would be a positive to restore it as soon as possible. But that is the purpose of having the CPRNG be robust. The seeds from last run are used until there is enough new entropy to reseed, and in the meantime the CPRNG provides the 'random' numbers. For most purposes this is more than adequate. If the CPRNG can be cracked with the short stream fed from it to start up the system, it is not robust. And that assumes that an attacker has complete access to that stream. The main threat from random numbers is that 'password' is a perfectly legitimate random string, so even hardware random number generators can generate easy to crack strings of numbers. That is, random doesn't mean strong cryptographically. What we really want are unpredictable crpytographically strong numbers. And that is also why it is so hard to validate random number generators; if they aren't failing the tests occasionally, they aren't random. But if they are failing the tests occasionally, it might or might not indicate they are not random, and thus predictable. And we might not even be testing the right thing! In any case, a good reason to randomly change seeds to CPRNGs regularly, if possible. Even a vulnerable CPRNG with a long stream required to crack it is robust if reseeded constantly at short intervals with randomness (the strategy of the linux kernel). _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
