On Thu, 2019-02-28 at 11:56 +0000, Ian Jackson wrote:
> Ben Hutchings writes ("Re: FYI/RFC: early-rng-init-tools"):
> > On Mon, 2019-02-25 at 19:37 +0200, Uoti Urpala wrote:
> > > Generally you don't ever
> > > need to use /dev/random instead of /dev/urandom unless you make
> > > assumptions about cryptography failing.
> >
> > I think I agree with that, but there is no way to add entropy that
> > unblocks getrandom() without also unblocking /dev/random. If the seed
> > files used in two different boots are somewhat correlated, and the
> > entropy estimation doesn't account for that, the output of /dev/random
> > may also be somewhat correlated between the boots, which is not
> > supposed to happen.
>
> I'm not sure what you mean by `somewhat correlated'.
I meant that they're not completely independent, so that knowing one
allows you to make some predictions about the other. But if I've
understood rightly, that doesn't matter as long as the entropy
estimation is right.
> Assuming that the random seed file is not copied, there is no weakness
> in copying entropy out of the kernel random pool and reinserting it on
> next boot, assuming that either (i) the entropy estimate provided on
> next boot is no bigger than the kernel's entropy counter at shutdown
> OR (ii) the kernel's PRNG was at any time properly seeded so that
> /dev/random unblocked.
I think this is right.
Ben.
--
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part