Re: Can we maybe reduce the set of packages we install by default a bit?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux