Am Freitag, 10. Januar 2014, 09:13:57 schrieb Clemens Ladisch: Hi Clemens, >Rafael Aquini wrote: >> 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? The concern this patch addresses is the following: Both pools have dissimilar use cases. Typically, the blocking_pool is used for cases where more "secure" random numbers shall be generated whereas the nonblocking_pool shall be used for any other case. The issue now is that both pools intended for different use cases are always updated with the same data. That means, we effectively have two different RNGs (the blocking and nonblocking pool) which are both (re-)seeded with the same data every time when invoking a write on /dev/?random. There is no way that the (re)seed operation mixes both pools with different values. Coming back to your concern: sure, the caller can pad any data injected into /dev/?random with zeros. 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. All the patch tries to achieve is to ensure that both pools are not always mixed with the same values. Hence, the patch does not change the entropy estimator operation. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
