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

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

Sam Hartman writes ("Re: FYI/RFC: early-rng-init-tools"):
> Ben Hutchings <ben@decadent.org.uk> writes:
> >[Someone:]
> >> 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.
> I see no problem crediting the secret stored across the reboot with the
> entropy in the pool at the time of shutdown.


AIUI the reason given for not doing this by default is that nowadays
many installations are VMs of some kind which may be cloned between
shutdown and startup.

This makes some kind of sense, although I am not sure that it is right
to break a lot of embedded systems for the benefit of people who do
that without care for cryptographic seeds.  Those are only one of
several things that need fixing up or working around when cloning a VM

> I agree that the credits for the entropy of the additional information
> added may be too high.
> I'm skeptical that the actual entropy credits matter much once you have
> *enough*, but I agree that the /dev/random interface does depend on
> that, and the proposal as described may be violating that assumption.

Linux /dev/random's notion that there is any difference between
`enough' entropy and `more' is wrong.  In particular its idea that
taking PRNG output out of /dev/random could cause degradation of any
kind is wrong.

IMO this is a serious and longstanding design defect in Linux's
/dev/random (which incidentally is not present in FreeBSD's
/dev/random which has had contact with actual cryptographers; and it
is not present in at least one of the newer syscall APIs but for
reasons best known to Linux developers, there is no simple /dev device
with the correct semantics).

So, it is of no consequence if Thorsten's scheme violates this
/dev/random entropy-counting principle.

I have a PhD in computer security - in particular, in cryptographic
protocol design.  But my knowledge is rather out of date since I left
academia and I have not reviewed Thorsten's design in detail.


Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply to: