Re: [PATCH 7/14] random: Remove SA_SAMPLE_RANDOM from network drivers

["Thiago Galesi" <thiagogalesi@gmail.com>]

> 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/