RFC possible changes for Linux random device

RFC possible changes for Linux random device

[Sandy Harris]

I have started a thread with the above title on Perry's crypto list. Archive at:
http://www.metzdowd.com/pipermail/cryptography/2014-September/022795.html

First message was:

I have some experimental code to replace parts of random.c It is not
finished but far enough along to seek comment. It does compile with
either gcc or clang, run and produce reasonable-looking results but is
not well-tested. splint(1) complains about parts of it, but do not
think it is indicating any real problems.

Next two posts will be the main code and a support program it uses.

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.

Re: RFC possible changes for Linux random device

[Nikos Mavrogiannopoulos]

On Mon, 2014-09-15 at 20:40 -0400, Sandy Harris wrote:

> I have some experimental code to replace parts of random.c It is not
> finished but far enough along to seek comment. It does compile with
> either gcc or clang, run and produce reasonable-looking results but is
> not well-tested. splint(1) complains about parts of it, but do not
> think it is indicating any real problems.
> 
> 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.

Hello,
 What are the advantages of this change? It was not clear from the
original thread.

regards,
Nikos