linux-kernel - Re: more random device badness in 2.6.18 :(

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:	Tue, 10 Oct 2006 23:13:02 +0200
From:	Michael Buesch <mb@...sch.de>
To:	Paul Wouters <paul@...erance.com>
Cc:	linux-kernel@...r.kernel.org, Gabor Gombas <gombasg@...aki.hu>,
	fedora-xen@...hat.com
Subject: Re: more random device badness in 2.6.18 :(

On Tuesday 10 October 2006 23:03, Paul Wouters wrote:
> On Tue, 10 Oct 2006, Gabor Gombas wrote:
> 
> > Why should Openswan touch /dev/hw_random directly?
> 
> Because using /dev/random whlie /dev/hw_random is available does not always
> work (eg with padlock)

Oh, wait wait. I don't really understand your sentence.
Why can't you use /dev/random?

> > There is a good reason why /dev/hw_random is different from /dev/random...
> 
> Why is this happening in userland? Will rng-tools run on every bare Linux
> system now? Including embedded systems? How about xen guests who don't have
> direct access to the host's hardware (or software) random?
> 
> 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?
> 
> 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.

/dev/hw_random should never be touched by anything else than rngd.
rngd takes the data from /dev/hw_random, _verifys_ it and puts it into
the normal /dev/random pools.
The verification step is really important.
So I would like to ask the other way around. Why should be put this code
into the kernel, while it works in userspace as good (or, some people may
argue it is even better in userspace, because it can more easily be exchanged,
debugged and configured. Whatever)

-- 
Greetings Michael.
-
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/