linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Henrique de Moraes Holschuh <hmh@hmh.eng.br>
To: Michael Buesch <mb@bu3sch.de>
Cc: Matt Mackall <mpm@selenic.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] hw_random: add quality categories
Date: Wed, 27 Jun 2007 13:40:41 -0300	[thread overview]
Message-ID: <20070627164041.GA6508@khazad-dum.debian.net> (raw)
In-Reply-To: <200706271458.51884.mb@bu3sch.de>

Hi Michael!

On Wed, 27 Jun 2007, Michael Buesch wrote:

> On Wednesday 27 June 2007 04:00:46 Henrique de Moraes Holschuh wrote:
> > On Tue, 26 Jun 2007, Michael Buesch wrote:
> > > On Tuesday 26 June 2007 16:06:25 Henrique de Moraes Holschuh wrote:
> > > > Which, AFAIK, we can quantify as the minimum expected entropy in the output.
> > > 
> > > The category is _not_ a measure of the entropy in the output.
> > > It is _just_ to get the chance to get a sane _default_ policy
> > > for which RNG is enabled by default, in the kernel.
> > > It's just about a default policy. _Nothing_ else.
> > 
> > Then why don't you call it "preference", or something to that effect?
> 
> Why? Because I did not get the same idea as you?
> So, please make up "preference" categories and give me some examples.

preference: 

	scalar, unsigned 32 bit value.  Higher values mean higher
	preference.

	values:

	0 - ANYTHING that has no peer-review papers for both design and
	implementation, done by third-parties with reasonable credence in
	the field.  Anything for which the expected minimum entropy per bit
	of output is unknown, or below 50%.  This includes all pseudo-random
	RNGs, as we are not evaulating the seeding here.

	Never use anything with preference zero by default.

	
	For H-RNGs that have their design and implementation public and
	peer-reviewed by at least one third-party with reasonable credence
	in the field, and for which the minimum worst-case expected entropy
	per bit of output is known and equal or higher than 50.000% (if it
	was reviewed, it will be known), calculate preference as follows:

	LSW (lower 16 bits) should be the average bandwidth of the RNG, in
	10^3 bit/s. Use 0 for RNGs slower than 10^3 bits/s.  Use 0xFFFF for
	RNGs faster than 65535*10^3 bits/s (if this scale is not good
	enough, I suggest one with 0 being 10^3 bit/s or lower, and 0xFFFF
	being 10^7 bit/s or higher).

	MSW (higher 16 bits) should be the expected worst-case minimum
	entropy per bit of output of the RNG with at least 1% confidence. 0
	means a minimum worst-case entropy per bit of output of 50.000%,
	0xFFFF means a minimum worst-case entropy per bit of output of
	99.999% or higher.


Add a "fail always" RNG device to select by default if only RNGs of
preference zero are available, and select by default the RNG with highest
preference (or the first one you find, in case of a tie), and you are set.

It is not perfect, but it at least it makes some sense.

There *is* a much better way to deal with it, though.  Add the fail always
RNG device, and always select it by default.  Let the user specifically set
which RNG he wants, and it now rates as "trusted", which is the only
fail-proof way to go about it IMHO.

-- 
  "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

  reply	other threads:[~2007-06-27 16:40 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-24 13:55 [PATCH] hw_random: add quality categories Michael Buesch
2007-06-24 14:30 ` Alexey Dobriyan
2007-06-24 14:43   ` Michael Buesch
2007-06-25 23:21 ` Andrew Morton
2007-06-26 13:56   ` Michael Buesch
2007-06-26  3:13 ` Matt Mackall
2007-06-26 14:06   ` Henrique de Moraes Holschuh
2007-06-26 14:20     ` Michael Buesch
2007-06-27  2:00       ` Henrique de Moraes Holschuh
2007-06-27 12:58         ` Michael Buesch
2007-06-27 16:40           ` Henrique de Moraes Holschuh [this message]
2007-06-27 17:56             ` Michael Buesch
2007-06-28  7:57               ` Henrique de Moraes Holschuh
2007-06-26 14:12   ` Michael Buesch
2007-06-26 14:32     ` Matt Mackall
2007-06-26 14:45       ` Michael Buesch
2007-06-27  3:18         ` Matt Mackall
2007-06-27 12:52           ` Michael Buesch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070627164041.GA6508@khazad-dum.debian.net \
    --to=hmh@hmh.eng.br \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mb@bu3sch.de \
    --cc=mpm@selenic.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).