| |||||||||||||
Appropriate sources of entropyAppropriate sources of entropyPosted May 22, 2008 2:40 UTC (Thu) by ikm (subscriber, #493)Parent article: Appropriate sources of entropy
> Removing the last remaining uses of IRQF_SAMPLE_RANDOM in network drivers seems likely, though some way to mix that data into the entropy pool without giving it any credit is still a possibility. Why is it just a possibility? I don't get it -- what could possibly be said against that? By following that route, you'd make dubious data hopefully a bit less dubious, but you wouldn't make it more dubious than it is already. So what's the downside? "All or nothing" syndrome?
(Log in to post comments)
Appropriate sources of entropy Posted May 22, 2008 10:42 UTC (Thu) by jmspeex (subscriber, #51639) [Link] > Why is it just a possibility? I don't get it -- what could possibly be said against that? I think they mean a possibility in terms of "it's possible to write code that isn't too ugly", rather than "possible" in the theoretical sense. Of course, the worst it can do is not increase the entropy. To actually decrease the entropy, if would need to be correlated to some other information in pool and cause really weird interactions (highly unlikely IMO).
Appropriate sources of entropy Posted May 22, 2008 15:19 UTC (Thu) by cpeterso (guest, #305) [Link] Linux's RNG does have code (a flag calleddont_count_entropy) to mix new entropy data into the entropy pool without increasing the entropy credits (i.e. /dev/urandom data would be more random but blocked /dev/random readers would not be woken up). But no code actually seems to take advantage of it.
Appropriate sources of entropy Posted May 24, 2008 5:09 UTC (Sat) by bronson (subscriber, #4806) [Link] The downside was just demonstrated by Debian. Mixing good randomness with dubious randomness seems harmless right? But what happens if the good randomness dries up? Will you notice? Will you end up using dubious randomness for something that matters?
Appropriate sources of entropy Posted May 24, 2008 6:50 UTC (Sat) by ikm (subscriber, #493) [Link] This is not like the Debian's situation. If dubious randomness isn't accounted for as incoming entropy bits, /dev/random would block the same way as it would be blocking without any dubious randomness at all. As for /dev/urandom, without any external randomness /dev/urandom would be looping inside sha1 feedback, acting as a pure PRNG. Any kind of external randomness injected into that loop would only make its randomness better, it can't possible make it worse (due to crypto properties of sha1 you can't forge any correlation here). Point is, when good randomness dries up, what you're getting from /dev/urandom is a PRNG output. Any dubious randomness mixed in could only improve this situation. So, to answer your question, you really won't notice in both cases, but your randomness would be a bit better if you mix in some dubious stuff there as well. In the latter case, your chances of using dubious randomness (pure PRNG) are actually smaller.
Appropriate sources of entropy Posted May 24, 2008 8:10 UTC (Sat) by bronson (subscriber, #4806) [Link] My point is, either you care about the strength of your random numbers or you don't. If you care, you're using /dev/random and you only mix in strong entropy. Mixing in weak entropy seems harmless but will mask problems that would otherwise be obvious. The Debian situation. If you don't care, then you're happy with a strong, well-seeded PRNG and there's no need to mix in dubious random data. Is there a middle ground? I don't see one.
Appropriate sources of entropy Posted May 24, 2008 18:47 UTC (Sat) by ikm (subscriber, #493) [Link] Any cryptographic PRNG needs to be reseeded once in a while, and some dubious data will do just fine for that, given that it is mixed in in a cryptographically secure way. A box with only a network connection is a good example of that -- it does not have much real entropy coming in. You say that in absence of any trusted entropy a crypto PRNG is never to be reseeded. I would disagree. One of the problem is what would happen if a seed file, which stores state across reboots, is compromised. Another acoounts for any sort of weaknesses found in a PRNG itself. If you need more details, see Schneier's Yarrow design paper, I could only agree with what he had to say. The point is, sticking to the one initial seeding forever is a bad idea.
|
|||||||||||||