[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <25204908.NQ7XpImiHx@positron.chronox.de>
Date: Tue, 26 Apr 2016 23:01:29 +0200
From: Stephan Mueller <smueller@...onox.de>
To: George Spelvin <linux@...izon.com>
Cc: herbert@...dor.apana.org.au, linux-crypto@...r.kernel.org,
linux-kernel@...r.kernel.org, sandyinchina@...il.com, tytso@....edu
Subject: Re: random(4) changes
Am Dienstag, 26. April 2016, 16:43:30 schrieb George Spelvin:
Hi George,
(I am not covering the initial part as I leave you time to read through the
paper which should cover those aspects)
>
> That's what I don't like about Intel's RDRAND and similar hardware RNGs:
> they are whitening too early.
>
> That's also what I don't like about XORing down to 1 bit before adding
> to the pool. Again, whitening too early!
>
>
> Is that any clearer?
I see what you are saying. And I know that the best way (TM) would be to
simply concatenate the time stamps. But that is not feasible.
And considering that I only want to have 0.9 bits of entropy, why should I not
collapse it? The XOR operation does not destroy the existing entropy, it only
caps it to at most one bit of information theoretical entropy. As I can show
that the original value has many more bits of entropy, I use that as my safety
margin.
Hence, I combine the safety margin provided by the XOR folding with a nice and
easy maintenance of the harvested one bit by simply concatenating them. Again,
the entire harvesting and collection shall be very easy to understand without
hiding anything. In addition it is intended to solely use XOR and
concatenation, i.e. the two only functions whose effect on entropy are known.
Ciao
Stephan
Powered by blists - more mailing lists