Re: [dsfjdssdfsd] what not to do... Wed, 02 April 2014 18:19 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 189F41A0354 for <>; Wed, 2 Apr 2014 11:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.81
X-Spam-Status: No, score=-0.81 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_LOCAL_NOVOWEL=0.5, J_CHICKENPOX_21=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PQt-6veBZ0mn for <>; Wed, 2 Apr 2014 11:19:00 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 508881A039D for <>; Wed, 2 Apr 2014 11:18:57 -0700 (PDT)
Received: by (Postfix, from userid 1001) id 955133F756; Wed, 2 Apr 2014 11:18:53 -0700 (PDT)
Date: Wed, 2 Apr 2014 11:18:53 -0700
To: Theodore Ts'o <>
Message-ID: <>
Mail-Followup-To: Theodore Ts'o <>, Donald Eastlake <>, "" <>, Sandy Harris <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Cp3Cp8fzgozWLBWL"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: Donald Eastlake <>, "" <>, Sandy Harris <>
Subject: Re: [dsfjdssdfsd] what not to do...
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "The dsfjdssdfsd list provides a venue for discussion of randomness in IETF protocols, for example related to updating RFC 4086." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 02 Apr 2014 18:19:04 -0000

On Wed, Apr 02, 2014 at 12:33:54PM -0400, Theodore Ts'o wrote:
> Some things that I might add as caveats is that the recommendations
> about using disk timing is based on research done decades ago, and
> disk drives have changed quite a bit since then.  I believe there
> probably is *some* entropy in spinning disks, but it may not be as
> much as possible.

And then there's SSDs.

> In the section about clocks, it might be worthy to note that on modern
> CPU's, very often many clocks are derived from a single master
> oscillator.  If there are subsystems where you have two clocks that
> are _not_ derived from the same oscillator, there may be an
> opportunity to pick up a few bits of entropy.  (And I suspect that's
> probably one of the remaining sources of entropy from disk drives
> these days.)

You have to be careful in many cases things look random but are not to
someone with the right insight (c.f. whitening); measurement is not

Quoting Clive Robinson on a common HWRNG design in chips:

Faux entropy consists of many things including the outputs of complex
processes and chaotic processes inherant as side effects of the design
process. One example of which is to have two free running oscillators
one running at high speed into the D input of a D-type latch and the
slower one going into the clock input of the D-type. Close in
observation of the Q output of the latch shows both metastability and
what appeares as random behaviour. However observation at a slower
time base shows "bunching" patterns that corespond on the timebase to
the lowest frequency difference of the two oscilators. And in fact if
driven into a suitable counter circuit will produce a sinusoudal
output count... Taking what is in effect an FFT of the random source
output will show up this determanistic wave, only if it is within the
FFT Window range...
Remediating... LIKE A BOSS