public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Phillip Susi <psusi@cfl.rr.com>
To: David Wagner <daw-usenet@taverner.cs.berkeley.edu>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Entropy Pool Contents
Date: Tue, 28 Nov 2006 12:42:15 -0500	[thread overview]
Message-ID: <456C74F7.3060902@cfl.rr.com> (raw)
In-Reply-To: <ekfifg$n41$1@taverner.cs.berkeley.edu>

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.



  parent reply	other threads:[~2006-11-28 17:41 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-11-22 23:54 Entropy Pool Contents Gunter Ohrner
2006-11-22 23:59 ` Gunter Ohrner
2006-11-23  0:10 ` Jan Engelhardt
2006-11-23 21:40   ` Gunter Ohrner
2006-11-27 16:16     ` Phillip Susi
2006-11-27 16:19       ` Chris Friesen
2006-11-27 18:54         ` Phillip Susi
2006-11-27 19:33           ` David Wagner
2006-11-27 20:38             ` Phillip Susi
2006-11-27 20:40               ` David Wagner
2006-11-27 21:52                 ` Kyle Moffett
2006-11-28  4:17                   ` David Wagner
2006-11-28  5:19                     ` Ben Pfaff
2006-11-28 12:13                       ` Henrique de Moraes Holschuh
2006-11-28 12:58                         ` David Wagner
2006-11-28 13:32                   ` Eran Tromer
2006-11-28 13:15                 ` Martin Mares
2006-11-28 17:22                   ` Phillip Susi
2006-11-28 17:24                     ` Martin Mares
2006-11-28 17:46                       ` Phillip Susi
2006-11-28 17:49                         ` Martin Mares
2006-11-28 18:40                           ` Phillip Susi
2006-11-28 21:05                             ` Martin Mares
2006-11-29 20:04                               ` Phillip Susi
2006-11-28 17:42                 ` Phillip Susi [this message]
2006-11-28 17:59                   ` Martin Mares
2006-11-28 22:50                   ` Eran Tromer
2006-11-27 22:21       ` Gunter Ohrner
2006-11-24  0:48   ` Theodore Tso
2006-11-24  1:01     ` Jeff Garzik
2006-11-23 20:54 ` Lennart Sorensen
2006-11-23 21:34   ` Gunter Ohrner
2006-11-23 21:04 ` Jeff Garzik
2006-11-23 21:43   ` Gunter Ohrner
2006-11-26  1:26 ` Folkert van Heusden

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=456C74F7.3060902@cfl.rr.com \
    --to=psusi@cfl.rr.com \
    --cc=daw-usenet@taverner.cs.berkeley.edu \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox