All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chris Friesen <cfriesen@nortelnetworks.com>
To: Oliver Xymoron <oxymoron@waste.org>
Cc: Alexander Viro <viro@math.psu.edu>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: Entropy from disks
Date: Tue, 29 Oct 2002 13:02:39 -0500	[thread overview]
Message-ID: <3DBECD3F.2080204@nortelnetworks.com> (raw)
In-Reply-To: 20021029171011.GD28665@waste.org

Oliver Xymoron wrote:

I'm not an expert in this field, so bear with me if I make any blunders 
obvious to one trained in information theory.

> The current Linux PRNG is playing fast and loose here, adding entropy
> based on the resolution of the TSC, while the physical turbulence
> processes that actually produce entropy are happening at a scale of
> seconds. On a GHz processor, if it takes 4 microseconds to return a
> disk result from on-disk cache, /dev/random will get a 12-bit credit.

In the paper the accuracy of measurement is 1ms.  Current hardware has 
tsc precision of nanoseconds, or about 6 orders of magnitude more 
accuracy.  Doesn't this mean that we can pump in many more bits into the 
  algorithm and get out many more than the 100bits/min that the setup in 
the paper acheives?


> My entropy patches had each entropy source (not just disks) allocate
> its own state object, and declare its timing "granularity".

Is it that straightforward? In the paper they go through a number of 
stages designed to remove correlated data.  From what I remember of the 
linux prng disk-related stuff it is not that sophisticated.


> There's a further problem with disk timing samples that make them less
> than useful in typical headless server use (ie where it matters): the
> server does its best to reveal disk latency to clients, easily
> measurable within the auto-correlating domain of disk turbulence.

If this is truly a concern, what about having a separate disk used for 
nothing but generating randomness?

Chris




-- 
Chris Friesen                    | MailStop: 043/33/F10
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com


  reply	other threads:[~2002-10-29 17:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-29 17:10 Entropy from disks Oliver Xymoron
2002-10-29 18:02 ` Chris Friesen [this message]
2002-10-29 19:08   ` Oliver Xymoron
2002-11-05 23:55   ` David Schwartz
  -- strict thread matches above, loose matches on Subject: below --
2002-11-06  0:27 Oliver Xymoron

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=3DBECD3F.2080204@nortelnetworks.com \
    --to=cfriesen@nortelnetworks.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oxymoron@waste.org \
    --cc=viro@math.psu.edu \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.