- Previous message: Rob Siemborski: "Re: Cyrus POP3 Issue"
- Maybe in reply to: L. Mark Stone: "Cyrus POP3 Issue"
- Next in thread: Marco Colombo: "Re: Cyrus POP3 Issue"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
|
|
|
From: Henrique de Moraes Holschuh (no email)
Date: Thu Mar 10 2005 - 18:21:36 EST
On Thu, 10 Mar 2005, Marco Colombo wrote:
> You seem to have too much faith in catastrophic reseeds, btw. If he's
> using the same sourcecode of the kernel, _his_ program is going to
> perform a reseed at the same time, in the same way. No matter how
No. We assume we have *some* entropy getting in, it is just not enough and
being drained too fast. That's the key.
Of course, the kernel would need to keep spare bits of *real* entropy for
reseedings that it has not used anywhere else. It probably is not doing
this right now, but it should be fixed to.
The reseed will NOT cause trouble for the attacker as far as he wants to go
_forward_ in time. He just breaks the state again, no big deal. But the
past will be unknown to him if he has no data about it.
So, reseeds are not going to protect future keys, anyway. They exist to
protect past keys, and to cause hassles if the PRNG and SHA1 break is not
perfect (e.g. it still takes a few days to do).
> Errors should be on the safe side. If not, it's a bug. And anyway, you're
It is a bug.
> referring to _root_ writing to /dev/random. You can, and actually should,
And? I was pointing out that there is no major reason to trust that code
blindly, it had a massive bug in it for a _long_ time, and nobody noticed.
> The kernel has little protection from root misbehaving.
This is not the issue, nor the bug at hand. In that bug, if I told the
kernel I gave it 256 bits of entropy (after feeding it 256 BYTES of
random data), it would act as if I gave it 128 BYTES of entropy in those 256
BYTES of random data.
> Again, that should never happen. AFAIK, it happens only when root increases
If there are no bugs.
> I think TCP needs entropy when establishing a new connection. I don't
> think anything needs entropy on _packet_ generation. Existing connections
> should be fine.
I might test this again one of these days. What I *know* is that my box
stopped talking to the network when I did a "cat /dev/random >/dev/null"
while testing rng-tools a few months ago. I have to check if that would
kill an ongoing TCP connection.
> doubts about SHA1), why getting entropy from the kernel at all? Just use
Because I don't think we should be implementing PRNGs everywhere if we can
help it. Too much chance for major fuckups.
> your own hashed PRNG in userspace. If you're using /dev/urandom only
> because it's there already, well, you're describing a _library_ not a
> kernel service.
True.
> >That source has H > 0.998, and I am already underestimating it to H=0.99,
> >which is good enough for my needs. I could be really paranoid and use 0.75
> >or even 0.5, but it is a slow source, so that would hurt.
>
> Interesting enough. :-) How do you know the real H? How do you measure it?
> Are you sure you're underestimating it?
For my usage, even if it is 0.8 and I use 0.99 it will still be good enough
:P Anyway, I am using this HRNG:
http://www.cryptography.com/resources/whitepapers/IntelRNG.pdf
I am trusting their research for the typical "H" instead of doing the hard
math myself, but that's because I am not using this thing on a C.A. :-)
> Why? You can have an userspace daemon buffer it. Writes on /dev/random
Which is exactly how I do it. See
http://arch.debian.org/cgi-bin/archzoom.cgi/--rng-tools-2005/rng-tools--hmh-devo?expand
> Why bloat the kernel with something that can easily be userspace? The only
Because, as I said:
> >I'd say that /dev/urandom *would* be an useless feature if we could trust
> >people to know what they are doing when writing their PRNGs. We cannot, so
> >we better improve urandom to have better resource reservation semanthics.
> I think we're slightly drifting off-topic. I'd end this thread here if you
> don't mind. For most cases, a DoS is worse, in practice, than a remote
> chance of total break at SASL/SSL level.
Sure. EOT.
-- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
|
|
|