linux-kernel - Re: Entropy Pool Contents

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <456C74F7.3060902@cfl.rr.com>
Date:	Tue, 28 Nov 2006 12:42:15 -0500
From:	Phillip Susi <psusi@....rr.com>
To:	David Wagner <daw-usenet@...erner.cs.berkeley.edu>
CC:	linux-kernel@...r.kernel.org
Subject: Re: 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 majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/