ntpkeygen patch

[Greg Rubin]

Gary,

On Fri, Jan 6, 2017 at 4:48 PM Gary E. Miller <gem at rellim.com> wrote:

> ...
> Unless you believe, as many do, that RDRAND is backdoored.
>
> FeeBSD refuses to use RDRAND:
>
>
> http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/
>
> OTOH, The Exalted Head Penguin prefers to jsut add it into a bigger mix:
>
> http://www.theregister.co.uk/2013/09/10/torvalds_on_rrrand_nsa_gchq/
>
> Both Linux and FreeBSD use RDRAND as input to /dev/urandom. They just
differ in how they do so. Linux mixes it in directly using XOR (a poor, but
not necessarily disastrous idea, depending on your threat-model) and
FreeBSD mixes it in after passing it through Yarrow.


> ...
> > FreeBSD does
> > the correct thing with blocking early on.
>
> And available to us in recent Python, but NTPsec is stuck supporting 2.6.
>
> My read of the documentation is that in FreeBSD sys_getrandom() and
/dev/urandom are essentially identical. It is in Linux where they differ
(with early blocking of entropy). I definitely like the idea of switching
to sys_getrandom() if available.


> > > Can we add entropy to the pool?
> > On systems with /dev/urandom, you can write data to it and it will
> > be  mixed into the entropy pool. Other systems may have other ways of
> > accomplishing this.
>
> Which misses the point, how do get the entopy to add to the pool?
>
> Well, there aren't many ways. It would take a lot of work, but that it how
we would add it if we had it.

> > Can we postprocess the urandom entropy to get more entropy?
> > There are post-processing steps which can be taken which will reduce
> > the risks associated with certain problems.
>
> Security by obscurity.  Not a good idea.  Only adding entropy helps.
>
> Not at all. Lack of entropy is not the only issue with RNGs. For example,
the notorious DUAL_EC_DRBG did not have a problem with entropy. Its problem
was that it leaked state to people who knew a certain secret.  FreeBSD is
(once again) an excellent example of doing things properly. They do not use
the output of RDRAND directly but rather use it to seed and reseed another
PRNG (Yarrow) and then use the outputs of Yarrow. This is a very safe way
of using RDRAND. So, if we really felt it worthwhile (and we shouldn't) we
could implement another trustworthy RNG (such as Yarrow, Fortuna,
AES_CTR_DRBG, HMAC_DRBG, etc.) and pass the input through there. This is
almost always a bad idea as we really don't want to be maintaining
cryptographic code like that. I call it out simply as an example of ways in
which you can take problematic (and possibly backdoored) data and safely
use it.

Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20170107/81bd0a16/attachment.html>