Date: Sun, 18 Aug 2013 18:20:57 +0100 From: Mark R V Murray <mark@grondar.org> To: Tim Kientzle <tim@kientzle.com> Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, secteam@freebsd.org, FreeBSD-arch Arch <freebsd-arch@freebsd.org> Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> In-Reply-To: <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=windows-1252
On 18 Aug 2013, at 17:53, Tim Kientzle <tim@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.
>=20
> 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.
=85 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=3D159 paragraph=3D4 typos_by=3Dmarkm>
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. ...=20
</quote>
M
--=20
Mark R V Murray
--Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.20 (Darwin)
Comment: GPGTools - http://gpgtools.org
iQCVAwUBUhECgN58vKOKE6LNAQopdAQAnqXrvAcJ8W/Iif7DPDaR7+xUVimN3soJ
btCfGClEyYWktmtcbSkmktR0bgMEN5P5he4/uTjvGoWjrK/uSyI5sYps4o+MgRwS
bSS5xhDKkeQFBb3lY+URl5g5r8fjHWiaAbktgDjICnuw4qBRYaTrzT0hy4EzD8+S
2NSaR/mwXNw=
=z3Km
-----END PGP SIGNATURE-----
--Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?537622E1-F785-4BFA-B829-09DCDB484606>