linux-kernel - Re: random(4) driver questions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110627145442.GA2729@thunk.org>
Date:	Mon, 27 Jun 2011 10:54:42 -0400
From:	Ted Ts'o <tytso@....edu>
To:	Sandy Harris <sandyinchina@...il.com>
Cc:	LKML <linux-kernel@...r.kernel.org>
Subject: Re: random(4) driver questions

On Sat, Jun 25, 2011 at 01:51:07PM +0800, Sandy Harris wrote:
> There was a paper some time back by a group of Israeli researchers
> and looking at the Linux /dev/random driver, and claiming to find
> it wanting in several ways. www.pinkas.net/PAPERS/gpr06.pdf
> 
> To what extent have their objections been dealt with. If some
> were considered bogus, is there documentation somewhere
> explaining why?

Suffice it to say the random generator has changed significantly since
2006.  There is now a secondary pool, which uses catastrophic
reseeding, etc.

> One problem they pointed out is that there may be little
> entropy available on a Linux-based router; no keyboard or
> mouse, solid state storage so no disk entropy, and an
> enemy might observe network activity, so network
> interrupts give little or no useful entropy.

Sure, but a Linux-based router shouldn't be doing crypto work.  If it
*is* and it is important crypto work, then it needs a hardware random
number generator.  There's no magic here.

If you don't want to pay the cost of a random number generator, you
can do things such as at installation time, bootstrapping the random
number generator with some cryptographically secure randomness
available by the installation system.

> The only in-kernel solution I can think of would be
> to add something in the system call interface to
> make very system call throw timing information
> into the pool. I very much doubt, though, that that
> is a good idea. What do others think, and does
> anyone have a better idea?

It won't hurt (aside from wasting CPU time, assuming you don't add any
entropy credits), but won't necessarily help, either.

> What happens to /dev/random when it runs on
> a virtual machine and all the things it relies on
> for entropy get virtualised away?
> 
> The server that the VM is hosted on will usually
> have plenty of entropy, often a hardware RNG.
> Is there an interface that makes that visible
> from the VM? Perhaps a virtual "hardware"
> RNG driven by /dev/urandom on the host?

Yes, paravirtualizing the random number generator would be a big help.
Probably what I would do is to periodically add entropy from the host
OS to the guest OS, via some paravirt channel.  This would add a new
"catastrophic reseeding", and if the virtual guest can mix in some
other unknown material, again that can only help.

						- Ted
--
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/