Re: [PATCH] hw_random: add quality categories

[Henrique de Moraes Holschuh]

On Mon, 25 Jun 2007, Matt Mackall wrote:
> On Sun, Jun 24, 2007 at 03:55:22PM +0200, Michael Buesch wrote:
> > This adds quality categories for hardware random number generators.
> > + * enum hwrng_quality - Quality identifier for RNG hardware
> > + * @HWRNG_QUAL_HIGH:	High quality RNG. Higher quality than
> > + * 			what is found on the usual PC mainboards.
> > + * 			Use that for special dedicated RNG
> > + * 			extension boards.
> > + * @HWRNG_QUAL_NORMAL:	PC-onboard-RNG devices.
> > + * @HWRNG_QUAL_LOW:	Low quality RNG devices. Use this for
> > + * 			devices which gather the entropy from possibly
> > + * 			bad sources, like the network.
> > + * @HWRNG_QUAL_PSEUDO:	Pseudo RNG device. Use this for devices
> > + * 			which are not RNG devices by definition, but
> > + * 			could be used as such. For example various
> > + * 			hardware sensors, like a motion sensor.
> 
> I don't think these definitions are very useful.

Agreed. They are horrible.

> There are basically three ways of measuring RNG quality:
> 
> a) does it generate a good spectrum based on an unpredictable physical
> process like Schott noise or free-running oscillator beat patterns?

Which, AFAIK, we can quantify as the minimum expected entropy in the output.

You can get output with the minimum expected entropy quite close to 1 from
good HRNGs.  Note that the same HRNGs might be configurable to disable the
whitener and output more bits, dropping to an expected minimum entropy of
0.75 for example (say hello, VIA Padlock!).

So quality is a property of (HRNG implementation, HRNG configuration when
the data was generated).

AFAIK, what really matters on a RNG is:

	0. trust on the design and implementation
	1. quality (minimum entropy expected on output)
	2. speed (minimum and average bits-per-second expected on output)
	3. whether it is implemented on software, or not.

Anything else is just *useless*.  And which RNG you should use (if you have
more than one available), based on the four attributes above, depends on
what you want to do.

> b) can the end-user trust that the design is implemented as described?

Heh, that's a hard one :-)  But I'd say HRNGs without at least a peer review
and open design are not to be trusted at all (which doesn't mean that those
which do have a peer review and open design can be trusted...).

> c) does it output lots of bits fast?

Yeah, you can go from a few bit/s, to some kbits/s, to megabits/s, it is a
damn important thing to know.

> Anything that fails (a) belongs in the PSEUDO class. This applies to
> RNGs where the implementation is undocumented too. (There's not much
> excuse for this as it costs negligible silicon to do this right.)

I'd say RNGs where the implementation is undocumented should not even be
supported at all...  but they certainly cannot be considered anything but
pseudo-random.

> Anything that passes (b) is something that the end-user built
> themselves while wearing their tinfoil hat.

Yes. Leave the user to decide whether they trust it or not.  And if the
kernel needs to know this, default to untrusted and let the user set a trust
level through some parameter.

> Anything that claims to be significantly better than the trivial
> circuit and whitening on a typical PC is probably marketing hype. 

Sort of.  But IMHO, such claims, when not backed by some hard paper analysis
the RNG design and output by third-parties, really are a reason to
*blacklist* the RNG and not use it at all.

> Which brings us down to (c). And basically all hardware RNGs are
> plenty fast enough.

Err... not really.  Intel's 82802AB or 82802AC-builtin RNG gives only ~24 *
10^3 bit/s, which is not much depending on what you are doing, for example.
While a VIA Padlock dual-HRNG CPU can easily output 1 * 10^6 bits/s of data
in its highest quality setting.  With such a bit amplitude of speeds
available, I really doubt you can say that all HRNGs are plenty fast enough.

> So that's basically three orthogonal axes: "real", "trusted", and
> "fast". And "trusted" trumps "real", which trumps "fast".

Heh. Indeed.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/