On Tue, 2019-02-26 at 22:29 +0200, Uoti Urpala wrote: > On Tue, 2019-02-26 at 19:10 +0000, Ben Hutchings wrote: > > But if the input to the seed doesn't provide enough entropy, the seed > > is not completely secret (that is, you can recover it with less work > > than a brute force search). The extreme example of this is the OpenSSL > > RNG debacle of some years back, where only the pid (15 bits) was used. > > > > Thorsten's implementation should yield rather more than 15 bits of > > entropy, but I think his entropy estimate is still over-optimistic. In > > the worst case the Linux RNG is used to generate a private key > > immediately on first boot, so the old seed file doesn't provide any > > additional entropy. (Either it doesn't exist or it's part of an image > > and not secret.) And in that case the space of possible keys may be > > small enough that it's feasible to recover the private key. > > While what you're saying here is not strictly speaking false, I think > it's missing the point, and is not a valid objection to the approach as > a whole. The core point of a program like this is that if you had a > secret state for the PRNG before boot, then rebooting *should not lose > that state* as long as you trust a file to stay secure over the boot. > There should be zero time needed to gather any new genuine entropy. > > The additional entropy gathered is for extra safety; it is not > *depended* on for basic security assumptions. [...]
It is, because the the kernel is told to treat it as providing a
certain number of bits of entropy.
Ben.
--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption]
would be development of an easy way to factor large prime numbers.
- Bill Gates
signature.asc
Description: This is a digitally signed message part
