cvs commit: src/sys/modules/random Makefile src/sys/dev/random harvest.c hash.c hash.h nehemiah.c nehemiah.h probe.c randomdev.c randomdev.h randomdev_soft.c randomdev_soft.h yar

[Alex Keahan]

On Sunday 11 Apr 2004 10:46 am, Mark Murray wrote:
> Nate Lawson writes:
> > > Still, opinion seems to be in favour of further postprocessing, so I'll
> > > do it.
> >
> > I haven't looked at the FreeBSD PRNG yet but why not seed Yarrow?

Sounds like a good idea.

> Yarrow's entropy accumulation and PRNG generator parts are disconnected
> (that is part of its point), so there is no connection between the
> number of bytes harvested and the number of bytes supplied. This
> makes a very long armoured pipeline between accumulation and issue,
> which seems like overkill when the suppied entropy is 99% OK (far
> better than Yarrow currently ever gets, BTW).

A cryptographically strong PRNG should not rely on a single source of
entropy, it should gather entropy from multiple sources.

> In adding a PRNG to the output of the nehemiah generator, I'd want
> to make something like
>
> output = hash(nehemiah_output());

Unfortunately this won't make the output of your PRNG any more unpredictable
than it already is.   If you can predict nehemiah_output(), you can also
calculate the hash of nehemiah_output().

> So that 1) the real entropy bytes are used almost immediately and
> 2) the number of bytes supplied to the user can be very tightly
> known.

A simple predictable hash-based PRNG which uses hardware as its only
source of entropy is no more secure than the hardware itself.

If someone can find a way to break the VIA PRNG (i.e. make it generate
predictable numbers), they will have broken your PRNG as well.

The Feds are going to love this "feature".   Now all they have to do is sell
you a system with a "customised" VIA chip, and they will have complete
control over your random numbers.

> Yarrow is unsuitable for this purpose; it is a great generator when
> you have a low-entropy environment and you need to protect against
> attackers having potential knowledge of the inputs.

And what makes you think it's not the case here?   "In VIA We Trust"?

AK