[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
The following reply was made to PR port-xen/40739; it has been noted by GNATS.
From: Christoph Badura <bad%bsd.de@localhost>
Cc: Manuel Bouyer <bouyer%antioche.eu.org@localhost>
Subject: Re: port-xen/40739: no entropy device sourcese on 5.0_RC2 XEN3PAE_DOMU
Date: Mon, 2 Mar 2009 23:32:52 +0100
[I have changed the order of the quoted text slightly.]
On Thu, Feb 26, 2009 at 08:20:06PM +0100, Manuel Bouyer wrote:
> On Thu, Feb 26, 2009 at 12:45:23PM +0100, Christoph Badura wrote:
> > I'm not sure I
> > buy the assertion that other domUs could interfere with the entropy
> > collection.
> I'm not a crypto expert, but another domU can cause predictible delays in
> disk I/O and I suspect this is bad for entropy.
> > What is the actual way to interfere with entropy collection, BTW?
> AFAIK entropy collection on peripherals is based on delays. Anything that
> can cause or add predictible delays to I/O can interfere.
There are two flaws in your argument: 1) entropy collection isn't based on
delay and 2) you haven't described an attack.
Entropy collection on peripherals is *not* based on delay. It is based on
jitter in the timing of interrupt delivery relative to a clock source in
the system. So, even if the I/Os would be delayed there would still be a
bit of jitter in the interrupt delivery and that jitter is the entropy that
rnd(4) filters samples for non-linear jitter and credits them with 1 bit of
entropy if they are judged random enough.
Assuming that someone is indeed able to "cause predictible delays in disk I/O"
what effects would that have?
The attacker can reduce the amount of entropy that is collected in a given
time frame. But there's still randomness to be found in anyway. Obviously
this situation is preferable to not collecting any entropy at all.
This isn't a reason to prevent the collection of entropy or to disable it
by default. If users run their domUs in such a hostile environment they
can disable entropy collection by themselves.
The commonly discussed attack is that an attacker may be able to figure
out the random data was handed to a security sensitive processes, say to
be used as nonce or key material. However, for this attack you need to
know the exact state of the random pool. And you can't know that by just
manipulating the delay of the I/O requests. You'd need access to the
actual memory that stores the data.
Neither scenario is a reason not to try to collect entropy from as many
sources as possible -- quite the contrary actually.
If you fear a flaw in or a breakdown of the algorithms inside rnd(4) that
is an orthogonal issue.
> > And if they did, wouldn't that then be true for xennet, too?
> it is, not only for xennet but for any interface on a shared network.
> that's why entropy collection on network interfaces is disabled by default
But being connected to a switch is *not* being on a shared network, because
it hides traffic from other machines in the same logical (sub) network.
> > Entropy collection from xbd isn't disabled in Xen2 domUs.
> that's a mistake.
I wonder on what authority you claim that? To me it looks very much like
you are pulling vague arguments out of thin air and demand that a crypto
researcher refutes them. If you want to continue this argument, why don't
you find and expert that backs up your claims?
I wonder on what authority you claim that? Your arguments seem very vague
to me. Please find and expert to back up your claims.
If you want to discuss this further, I suggest we take it to tech-security.
In the mean-time I don't see why we should cripple rnd(4) in domUs by default.
Users who are extra paranoid can disable the sources with rndctl(8).
P.S. yes, I looked at quite a bit of background literature on this and
read the rnd(4) sources.
Main Index |
Thread Index |