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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
