[Cryptography] [RNG] /dev/random initialisation

[dj at deadhat.com]

> On Oct 27, 2013, at 6:17 PM, John Denker <jsd at av8n.com> wrote:
> ...
>> On 10/24/2013 07:59 AM, John Kelsey wrote:
>>

>> a) If you have 256 bits of honest-to-goodness entropy from
>> /any/ source, OS or otherwise, then that's more than enough
>> to seed the PRNG, and nothing on the list matters.
>
> Right.  My point is that we want to consider the possibility that one or
> more of our sources aren't good, but we don't know which.  For any
> minimally decent PRNG, if we feed it 128 bits of entropy plus a million
> bits the attacker gets to choose, we should still get a secure PRNG state.
>

But the specifications (SP800-90x & FIPS 140-2) make it spectacularly hard
to mix in multiple sources in a compliant way. SP800-90 gives a way to mix
in "additional entropy" and "personalization strings", but FIPS 140-2
states that all sources must be authenticated. All configuring entities
must be authenticated. Try authenticating hardware on one end of chip
against hardware at the other end of the chip. It is the mother of all
chicken and egg problems.

The 'per instance' nature of the additional entropy data provided during
the SP800-90A instantiation algorithm is entirely incompatible with
hardware implementations that have fixed state.

The solution is to not use or permit any of these extraneous inputs and
don't permit instantiation other than at reset time, then you don't need
to go about 'authenticating' the caller, whatever that means in the
context of one circuit on a chip talking to another circuit on a chip.
Just so you can take it in for FIPS certification.

SP800-90A defines a reseed as a callable function and defines the caller
as being the thing that provides the fresh entropy. FIPS 40-2 requires
that the caller be authenticated. That's what I call a mess.

If NIST want people to make compliant paranoia RNGs, that accept all
sources, authenticated or not, and mix them, then that is what the specs
should say, but they do not. All sources have to have been designed in
ahead of time. All entities it interacts with have to have been
provisioned with authentication credentials.

So the 'mix everything in' RNGs give one model of security (Only 1 of N
sources need be good). The NIST RNGs give another (We designed the one
true source to be good). But there is no overlap. One cannot be both a
NISTesque RNG and a 'mix everything in' RNG.

I have heard this complaint from multiple people on multiple projects -
paraphrasing: "We had to make our RNG less secure to get it through FIPS -
We had to take out the additional mix in sources".