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

[Poul-Henning Kamp]

In message <200404122235.aa56194 at salmon.maths.tcd.ie>, David Malone writes:

>It is still no good for generating keys that have more unpredictable
>bits than Yarrow's internal state, unless you can be sure that it
>has reseeded. For example, the Yarrow paper notes that there is no
>point using Yarrow-160 for generating 256 bit block cipher keys and
>that using it for things like one time pads are right out.

Given that I'm one of the largest consumers of random bits in the
kernel (in GBDE), I would like to chime in with a few observations:

In most of cryptography, it is not about making things absolutely
secure (which is impossible), it is about making things secure
enough.  Typically a good criteria for this is to pinpoint another
vastly cheaper attack strategy.

Even with the very limited randomness we provide to yarrow with the
normal setup, any attacker who is able to manipulate or predict the
random bits you get/got, would be in a position to inflict so much
more harm on you in other ways that he would not care about your
random bits.

Still, we have to be weary of systematic errors, both in Yarrow,
but more so in the output from RNG HW because otherwise it may not
remain so.

I therefore think that we should retain a crypto/yarrow afterburner
on all random sources, but it may make sense to have offer different
grades of random bits for performance reasons.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
phk at FreeBSD.ORG         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.