Le 03/04/2012 13:21, Brian J. Murrell a écrit :
On 12-04-03 04:52 AM, Dave Taht wrote:
I was wondering why hostapd (on cerowrt 3.3) ate so much cpu, even when
idle, nothing connected, no crypto enabled...
I'm curious as to if this is correct behavior, and what's the point of
writing 000s to /dev/random,
Is it supposed to be feeding the entropy pool (i.e. perhaps from RF
noise for example) for the kernel's random number generator? I'm really
not sure if writing into /dev/random does feed the entropy pool or not,
but just guessing here.
Cheers,
b.
That's strange. Normally, if someone is to do that, then it shall be done
in the kernel. Application tends to have a reproducible behavior that makes
this entropy far more predictable than, say, the timing of generated wifi
interrupts (if there are any).
The fact is: writing bytes in /dev/random does NOT change the advertised
entropy - it merely changes the bytes that are to be read. So this operation
is likely a non-interesting one, as the bytes to read will be just as hard
to predict with and without this op. See linux/driver/char/random.c for
further reference [1].
Moreover, in this very, very specific case (where the application writes a
predicatble number of 0s), an additional cryptoanalysis is very likely to
be necessary: the pattern, when mixed in the random buffer, might in fact
lower the real entropy delivered by the char device.
IMHO, I would consider this as a "possibly dangerous" behavior, and I would
probably remedy to this situation using a simple yet effective solution:
removing the offending code, as it doesn't change anything in terms of
security and functionnality.
-- Emmanuel Deloget
[1] the write_pool() function ends up calling mix_pool_bytes_extract(),
which has the following comment:
/*
* This function adds bytes into the entropy "pool". It does not
* update the entropy estimate. The caller should call
* credit_entropy_bits if this is appropriate.
*
* The pool is stirred with a primitive polynomial of the appropriate
* degree, and then twisted. We twist by three bits at a time because
* it's cheap to do so and helps slightly in the expected case where
* the entropy is concentrated in the low-order bits.
*/
See http://lxr.linux.no/linux+v3.3.1/drivers/char/random.c#L456 for
further information. Needless to say, write_pool() do not call
credit_entropy_bits(), and therefore does not change the advertised
entropy.
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
