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]
Date:	Wed, 11 Oct 2006 01:32:14 +0200
From:	Gabor Gombas <gombasg@...aki.hu>
To:	Paul Wouters <paul@...erance.com>
Cc:	fedora-xen@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: more random device badness in 2.6.18 :(

On Tue, Oct 10, 2006 at 11:03:58PM +0200, Paul Wouters wrote:

> Why is this happening in userland?

Because whether the provided data is "random enough" is a policy
decision, and policy does not belong in the kernel.

> Will rng-tools run on every bare Linux
> system now? Including embedded systems?

Why not? Alternatively you can always create your own version. Open
source does not mean you get everything for free; it means you _can_ do
the work if you want to.

> How about xen guests who don't have
> direct access to the host's hardware (or software) random?

If they don't have access to the host's hardware, then they do not have a
/dev/hw_random device. What's your question? And how that's different
from machines not having a hw rng at all?

> Why is this entropy management not part of the kernel? So for Openswan to
> work correctly, it would need to depend on another daemon that may or may
> not be available and/or running?

No. It only has to depend on /dev/(u)random. How the entropy is obtained
(from /dev/hw_random, from the soundcard's white noise or from
elsewhere) is none of Openswan's business.  Tha'ts up to the system
administrator or distribution maker to decide and set up.

> I still believe /dev/random should just give the best random possible for
> the machine. Wether that is software random, or a piece of hardware, should
> not matter. That's the kernel's internal state and functioning.

Gabor

-- 
     ---------------------------------------------------------
     MTA SZTAKI Computer and Automation Research Institute
                Hungarian Academy of Sciences
     ---------------------------------------------------------
-
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