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

On Sun, Feb 19, 2006 at 10:51:15AM -0500, Thor Lancelot Simon wrote:
>=20
> A major problem with our /dev/random implementation is that it obscures
> the actual input data while doing no testing at all to ensure that it is
> actually random.  It is a very bad idea to leave known-questionable
> sources -- particularly ones with high data rates -- connected to it!

I sympathise, but I have yet to see a convincing argument that this is
actually the case, or of what harm this can actually bring (beyond
consumption of cpu cycles for little benefit).

Don't get me wrong, I would be delighted if someone does come forward
with such an argument, and settle what has otherwise been an area of
pure speculation - but until they do, comments like this seem to
overstate the established case.

What matters most is the number of good random inputs, so I'd
certainly support a weaker form of the assertion: that relying only on
such a source in the belief that it is good, or excluding other
possible sources from the mix as a result, is a bad idea.  That
includes allowing /dev/random to unblock based on pchb input alone,
because of giving it rndctl 'estimate' flags - its rate *will* drown
out other sources in this aspect, at least.

Of course, I fully support calling 'snake oil' on chips that falsely
claim to have an rng feature, regardless.  If some chips from the same
vendor actually do have legitimate medicinal properties, but are
discredited by association because it's too hard to tell the
difference, so be it: this is the risk a vendor takes in peddling
snake oil.

--
Dan.
--wwtQuX191/I956S7
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iD8DBQFD+N7EEAVxvV4N66cRAmolAKCNTaQMHKEu6MbpSwskqQiKXWAyUQCgjRhd
8/l/Nrpfbv+1EyJZVm2I35k=
=US+0
-----END PGP SIGNATURE-----

--wwtQuX191/I956S7--