Re: [RFC PATCH] char: random: stir the output pools differently when the random_write lenght allows splitting the seed

Stephan Mueller wrote:

Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch:

quoted

Rafael Aquini wrote:

quoted

This patch introduces changes to the random_write method so it can
split the given seed and completely stir the output pools with
different halves of it, when seed lenght allows us doing so.

-	ret = write_pool(&blocking_pool, buffer, count);
+	ret = write_pool(pool1, buffer, count1);
 	if (ret)
 		return ret;
-	ret = write_pool(&nonblocking_pool, buffer, count);
+	ret = write_pool(pool2, buffer + offset, count2);

Doesn't this assume that both halves of the buffer contain some
(uncredited) entropy?  In other words, wouldn't this result in worse
randomness for pool2 if the second half of the buffer contains just
zero padding?

[...]
Coming back to your concern: sure, the caller can pad any data injected
into /dev/?random with zeros.

Assume that the userspace of an embedded device wants to do the same
kind of initialization that a call to add_device_randomness() does, and
that it has some data like "char serial_number[256]".  The padding
wouldn't be done intentionally, it's just a property of the data (and it
wouldn't have mattered before this patch).

But as writing to the character files is allowed to every user, this
per definition must not matter (e.g. an attacker may simply write
zeros or other known data into the character file). And the random.c
driver handles that case appropriately by not increasing the entropy
estimator when receiving data.

The problem is not with the entropy estimate.

All the patch tries to achieve is to ensure that both pools are not
always mixed with the same values.

Before this patch, both pools got mixed with the same values.  After
this patch, both pools indeed get mixed with different values, but now
one pool gets mixed with a known value if one half of the buffer happens
to be known.


Regards,
Clemens