[lkml]   [2006]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Entropy Pool Contents
First, please don't remove the Cc: list.

David Wagner wrote:
> Sorry, but I disagree with just about everything you wrote in this
> message. I'm not committing any logical fallacies. I'm not assuming
> it works because it would be a bug if it didn't; I'm just trying to

>> Nope, I don't think so. If they could, that would be a security hole,
>> but /dev/{,u}random was designed to try to make this impossible, assuming
>> the cryptographic algorithms are secure.

That sure reads to me like you were saying that it would be a security
hole, so that can't be how it works. Maybe I just misinterpreted, but
at any rate it is a non sequitur, so let's move on.

> help you understand the intuition. I have looked at the algorithm
> used by /dev/{,u}random, and I am satisfied that it is safe to feed in
> entropy samples from malicious sources, as long as you don't bump up the
> entropy counter when you do so. Doing so can't do any harm, and cannot
> reduce the entropy in the pool. However, there is no guarantee that
> it will increase the entropy. If the adversary knows what bytes you
> are feeding into the pool, then it doesn't increase the entropy count,
> and the entropy estimate should not be increased.

I still don't see how feeding tons of zeros ( or some other carefully
crafted sequence ) in will not decrease the entropy of the pool ( even
if it does so in a way that is impossible to predict ), but assuming it
can't, what good does a non root user do by writing to random? If it
does not increase the entropy estimate, and it may not actually increase
the entropy, why bother allowing it?

> - Whether you automatically bump up the entropy estimate when
> root users write to /dev/random is a design choice where you could
> reasonably go either way. On the one hand, you might want to ensure
> that root has to take some explicit action to allege that it is
> providing a certain degree of entropy, and you might want to insist
> that root tell /dev/random how much entropy it added (since root
> knows best where the data came from and how much entropy it is likely
> to contain). On the other hand, you might want to make it easier
> for shell scripts to add entropy that will count towards the overall
> entropy estimate, without requiring them to go through weird
> contortions to call various ioctl()s. I can see arguments both
> ways, but the current behavior seems reasonable and defensible.

I would favor the latter argument since the entropy estimate is only
that: an estimate. Trying to come up with an estimate of the amount of
entropy that will be added to the existing unknown pool after it is
stirred by the new data seems to be an exercise in futility.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2006-11-28 18:45    [W:0.094 / U:15.280 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site