[Cryptography] Uncorrelated sequence length, was: A TRNG review per day
David Leon Gil
coruus at gmail.com
Sat Oct 25 09:02:51 EDT 2014
On Sat, Oct 25, 2014 at 5:51 AM, Bill Cox <waywardgeek at gmail.com> wrote:
> On Fri, Oct 24, 2014 at 7:32 PM, David Leon Gil <coruus at gmail.com> wrote:
>> The current provable-security bounds on recovering from state
>> compromise require anywhere from 2KiB to 20 KiB of input entropy to
>> recover from "state compromise". See section 5.3 of
>> http://www.cs.nyu.edu/~dodis/ps/prematureNext.pdf
>>
>> So, perhaps some applications would want a fairly large amount of entropy.
> However, I just went and looked a bit at random.c. I would have to look a
> *lot* harder to feel confident I am reading it right, but at first glance,
> it's mixing function, _mix_pool_bytes does not satisfy my assumptions above.
> It does not appear to be a cryptographically secure hash function. It
> simply stirs data in the pool weakly, counting on lots of entropy data to
> make that OK.
That's fully accurate. (In fact, an earlier paper by Dodis points out
that /dev/random is broken at present:
http://www.cs.nyu.edu/~dodis/ps/rng.pdf )
> This seems insecure to me, but I suppose there are probably reasons for the
> Linux kernel to weakly mix the input entropy rather than performing a secure
> hash.
No good reasons; OSX (and some BSDs?), for example, uses Schneier's
Fortuna RNG, which is cryptographically sensible.
> If I were writing that code, I'd turn Blake2b into a sponge (similar
> to Lyra2), and would only mix in entropy once I'd collected at least 256
> bits worth. That way, the state becomes secure again on every update.
That would be better than what the Linux kernel is doing...
I believe that some folks are working on code to fix /dev/random, but
it's a fair amount of work to write / get merged.
> Can I use a simple hack to insure the Linux entropy is secure after every
> write to /dev/random? I am thinking of force-feeding it 4096 bits from the
> Keccac sponge, rather than just 512 bits like I do now. Is my reading of
> random.c's mixing accurate? Will this hack insure that the entropy pool is
> securely refreshed?
Not sure.
More information about the cryptography
mailing list