Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 21 Aug 2012 08:55:04 +1000
From:      Peter Jeremy <peter@rulingia.com>
To:        Ben Laurie <ben@links.org>
Cc:        freebsd-arch@freebsd.org
Subject:   Re: /dev/random
Message-ID:  <20120820225504.GA78528@server.rulingia.com>
In-Reply-To: <CAG5KPzwBzWvDFDZqzT4masbknKfVe-rvdTd1h6ZxEoG90Rcxqg@mail.gmail.com>
References:  <CAG5KPzz4GQ2C_ky_qrDroQ4srGL4daW0OO-F3eOvvL-9AO6zoQ@mail.gmail.com> <20120820220243.GA96700@troutmask.apl.washington.edu> <CAG5KPzwBzWvDFDZqzT4masbknKfVe-rvdTd1h6ZxEoG90Rcxqg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--sm4nu43k4a2Rpi4c
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2012-Aug-20 23:05:39 +0100, Ben Laurie <ben@links.org> wrote:
>> Well, it's hard to comment when you failed to explain
>> *why* you think it is a mistake.
>
>Sorry - because I do not think it is wise to trust the h/w prng so
>much we discard other entropy.

This depends on the relative predictability of Yarrow vs the hardware
RNG.  FreeBSD random(4) currently only supports one hardware RNG - the
one in the VIA Nehemiah.  VIA have published an independent evaluation
of their RNG which suggests it is a good source of entropy.
Additionally, the RNG is not used in a raw form, instead a Davies-
Meyer hash is performed using the AES-128 CBC with random key, IV and
data to further whiten the output.  I am not sure whether anyone has
done any comparison of the relative randomness of these approaches.

>That is everything except the hardware, right? So ... all other sources.

The FreeBSD random(4) device implementation currently allows only one
RNG to be active at a time, though it should be possible to create a
kernel thread that regularly adds entropy from a hardware RNG to the
Yarrow state.

>It is relevant because it seems there is entropy available in
>fine-grained timing.

Part of the entropy harvested at each of the sampling points is
the CPU cyclecounter (eg TSC).  It's difficult to see what finer
grained timing you expect to be used.

--=20
Peter Jeremy

--sm4nu43k4a2Rpi4c
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)

iEYEARECAAYFAlAywEgACgkQ/opHv/APuIcFKwCfd10vSexKn3uwiqV+8rsGcN3J
/BkAniKFchi+OQNUky8sYPh4GN5ZZ+8q
=xPYF
-----END PGP SIGNATURE-----

--sm4nu43k4a2Rpi4c--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120820225504.GA78528>