Messages in this thread | | | Date | Sun, 7 May 2006 10:13:50 -0300 | From | "Thiago Galesi" <> | Subject | Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers |
| |
> Sure. > > First, since the existence of /dev/random's entropy accounting scheme > is predicated on the assumption that we can break the hash function at > will, I'll replace SHA1 with, oh, say, CRC-16. This'll be illustrative > until someone has a nice preimage attack against SHA1. > > Then I'll run my test on one of the various arches where HZ=~100 and > we don't have a TSC. Like Sparc? > > Now all the inputs are easily predictable from anywhere with <10ms > ping, with the occassional need to guess between a pair of timer > ticks. And since I can calculate preimages of CRC-16, I can now deduce > the state of the pool if I can watch some subset of its output, say > https session keys I request. And then I can start guessing future > outputs and breaking into other people's https sessions. > > The point of /dev/random is to -survive- SHA1 being broken by never > giving out more secrets than we take in.
OK, here goes...
1 - by eliminating feeding enthopy from network cards you are eliminating all sources of enthropy for _lots_ of people (think headless servers, embedded systems - even though there can be other sources of enthropy there) Unfortunatelly, bad enthropy is still better than no enthropy (just think - no ssh / https, etc, etc)
2 - some platforms have much better enthropy sources than ethernet (or user input), just think hardware rngs, or even the sound card rng thing mentioned above
3 - as people said, your example (CRC-16 on specific platfoms) is (IMHO) an exxageration. Of course, /dev/random should try and protect us from whatever protocol being broken. That being said, this protection should be 'realistic'. In theory most things are broken if we have enough equipment and computing power.
My conclusion, I have no problem removing SA_SAMPLE_RANDOM *IN SPECIFIC CASES* (meaning, this should be user configurable). In a secure environment / platform has rng, it could be turned off, and in a headless server / embedded system / it could be left on.
Of course, that's just MHO...
Thiago - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |