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
Attachment:
signature.asc
Description: This is a digitally signed message part