random(4) plugin infrastructure for mulitple RNG in a modular fashion

[Mark R V Murray]

On 18 Aug 2013, at 17:53, Tim Kientzle <tim at kientzle.com> wrote:
> We could have kernel options to choose mixers
> (e.g., Yarrow or Fortuna) for /dev/random and
> loadable device modules for entropy sources.
> 
> Besides Yarrow and Fortuna mixers, we could then
> offer a "null mixer" option that selected the single
> "best" entropy source and passed it directly through.

… assuming that it is "real" entropy and not unprocessed
stuff like keystrokes, mouse moves etc.

Code needed.

> Users could compile the null mixer into the kernel
> and load a single HW RNG driver to have precise
> control over /dev/random.  Interrupt harvesting would
> be the lowest-quality source as a fall back.

There are lots of harvest points in the kernel. Why not
take the lot?

> In particular, this has a reasonable failure mode if
> someone built a kernel with only a single HW entropy
> source and the null mixer:
>  * On hardware with that source, they would get
>     full-speed HW entropy.

OK. Works for me. This is me accepting a point and
changing my stance.

This will need to be written.

>  * On hardware without that source, they would get
>     the old blocking /dev/random that we had before
>     Yarrow, the one that used only interrupt harvesting.

Disagree. The fallback should be Yarrow/Fortuna. Both
do a better job with the same input.

See:
Furguson, Niels & Schneier, Bruce.
"Practical Cryptography"
ISBN 0-471-22894-X
     0-471-22357-3

<quote page=159 paragraph=4 typos_by=markm>
There is a theoretical argument that real random data is better than pseudorandom data from a PRNG. In certain cryptographic protocols you can prove that certain attacks are impossible if you use real random data. The protocol is unconditionally secure. If you use a PRNG, then the protocol is only secure as long as the attacker cannot break the PRNG; the protocol is computationally secure. this distinction, however, is only relevant for people in ivory towers. All cryptographic protocols use use computational assumptions for for almost everything. Removing the computational assumption assumption for one particular type of attack is an insignificant improvement, and generating real random data, which you need for unconditional security, is so difficult that you are far more likely to reduce the system security by trying to use real random data. ... 
</quote>

M
-- 
Mark R V Murray

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 353 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130818/5db19efe/attachment.sig>