[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <BANLkTinC7vfaRWf5TK9gJuQVtVwDkEQFcQ@mail.gmail.com>
Date: Sat, 25 Jun 2011 13:51:07 +0800
From: Sandy Harris <sandyinchina@...il.com>
To: LKML <linux-kernel@...r.kernel.org>
Subject: random(4) driver questions
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?
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.
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?
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?
--
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