[Cryptography] RFC possible changes for Linux random device

[Jonathan Thornburg]

On Fri, Sep 12, 2014 at 07:18:58PM -0400, Sandy Harris wrote:
> I have some experimental code to replace parts of random.c 
[[...]]
> I change nothing on the input side; the entropy collection and
> estimation parts of existing code are untouched. The hashing and
> output routines, though, are completely replaced, and much of the
> initialisation code is modified.
> 
> It uses the 128-bit hash from AES-GCM instead of 160-bit SHA-1.
> Changing the hash allows other changes. One design goal was improved
> decoupling so that heavy use of /dev/urandom does not deplete the
> entropy pool for /dev/random. Another was simpler mixing in of
> additional data in various places.

Without knowing the full set of design goals and the threat model,
it's very difficult to evaluate the code.  That is, we don't know what
you're trying to accomplish -- is your new code supposed to
* be faster?
* to be stronger against cryptographic analysis of its output?
* provide high-quality randomness earlier in the boot sequence?
* use less kernel memory?
* be more resistant to cache or timing attacks by malicious user code
  running the local processor?
* more resistant to cache or power-consumption side-channel attacks
  mounted by an attacker with physical (but not software) access to
  the local processor & memory?
* be more resistant to timing attacks by attackers on the local network?

-- 
-- "Jonathan Thornburg [remove -animal to reply]" <jthorn at astro.indiana-zebra.edu>
   Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA
   "There was of course no way of knowing whether you were being watched
    at any given moment.  How often, or on what system, the Thought Police
    plugged in on any individual wire was guesswork.  It was even conceivable
    that they watched everybody all the time."  -- George Orwell, "1984"