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/[EMAIL PROTECTED]/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
