linux-kernel - Re: RNG: is it possible to spoil /dev/random by seeding it from (evil) TRNGs

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:	Mon, 08 Oct 2012 02:41:31 +0200
From:	Christoph Anton Mitterer <calestyo@...entia.net>
To:	Theodore Ts'o <tytso@....edu>
Cc:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: RNG: is it possible to spoil /dev/random by seeding it from
 (evil) TRNGs

Hi Ted.

Thanks for your prompt reply.

On Thu, 2012-10-04 at 18:49 -0400, Theodore Ts'o wrote:
> It is impossible by design.  Or specifically, /dev/random was designed
> so that it can be world-writeable, and an attacker can feed in any
> kind of input he or she wants, and it will not allow the attacker to
> know anything more about the state of the entropy pool than he or she
> knew before they started mixing inputs in.

I just wondered because I remembered David Shaw (one of the main
developers from gpg) to imply[0] some time ago, that an "evil" entropy
source would actually be a problem:
> Not completely useless given the Linux random design, but
> certainly an evil source of entropy would be a serious problem.  "

> There are comments that go into more detail about the design in
> drivers/char/random.c.
I had a short glance at it,... but I guess it goes a bit above my
understanding of entropy theory... well at least without without putting
some effort into it.

Some notes though (guess you're the maintainer anyway):
1) With respect to the sources of entropy... would it make sense for the
kernel to follow ideas from haveged[1].
I mean we all now that especially disk-less server systems have problems
with the current sources.
Or is that intended to be kept in userspace?

2) At some places, the documentation mentiones that SHA is used... any
sense in "upgrading" to stronger/more secure (especially as it says the
hash is used to protect the internal state of the pool) and faster
algos?

3) Some places note that things are not so cryptographically strong...
which sounds a bit worrying...

4) Were "newer" developments in PRNGs already taken into account? E.g.
the Mersenne Twister (which is AFAIK however not cryptographically
secure; at least in it's native form)

Thanks again,
Chris.

[0]
http://lists.gnupg.org/pipermail/gnupg-users/2009-September/037301.html
[1] http://www.issihosts.com/haveged/
[2] http://www.math.sci.hiroshima-u.ac.jp/~m-mat/MT/emt.html

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5450 bytes)