lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070627164041.GA6508@khazad-dum.debian.net>
Date:	Wed, 27 Jun 2007 13:40:41 -0300
From:	Henrique de Moraes Holschuh <hmh@....eng.br>
To:	Michael Buesch <mb@...sch.de>
Cc:	Matt Mackall <mpm@...enic.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] hw_random: add quality categories

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ