Web lists-archives.com

Re: FYI/RFC: early-rng-init-tools




On Mon, 2019-02-25 at 14:36 -0500, Sam Hartman wrote:
> > > > > > "Ben" == Ben Hutchings <ben@xxxxxxxxxxxxxxx> writes:
> 
>     Ben> The output of the RNG may well become public, for example in
>     Ben> document UUIDs.  So when estimating the entropy that the new
>     Ben> seed file will provide for the next boot, none of the entropy
>     Ben> in the old seed file should be credited.
> 
> Are you saying that you believe that given output from the RNG it is
> cryptographically feasible to determine the seed?
> 
> There's a trivial reduction from that claim to a proof that the PRNG is
> not in fact a PRNG.
> 
> Unless there are cryptology results I'm unaware of--and it has been a
> few years since I studied the construction of PRNGs--then I don't think
> your argument is reasonable.
> A PRNG should be secure so long as its seed stays secret.
[...]

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.

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