[Cryptography] [RNG] /dev/random initialisation

John Kelsey crypto.jmk at gmail.com
Tue Oct 29 23:59:53 EDT 2013


On Oct 28, 2013, at 5:28 PM, dj at deadhat.com wrote:

...
> 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.

Wait, the FIPS labs refuse to let you put your own stuff into those additional inputs?  That's the whole *point* of having them in the DRBGs.  If you call generate with an additional input that is not guessable to the attacker, starting with a DRBG state the attacker knows, the DRBG is put into an unguessable-to-the-attacker state before the output bits are generated.  

> 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.

One thing that's probably causing some confusion somewhere is that 800-90A really just specifies deterministic algorithms.  90B (which is still being worked on) specifies entropy sources, and 90C (also still being worked on) specifies how to combine the two kinds of components to get a working random bit generator.  I gather the FIPS guys are trying to impose some kinds of requirements while they wait for these to be done.  But there is no way it makes sense to restrict the DRBG additional inputs to only coming from an authenticated on-device location.  

> 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.

Our goal is to have a trusted entropy source in there somewhere, since otherwise you can't really know you are starting up into a secure state.  But there should not be any restrictions on where the additional inputs can come from.  

There's also an idea of combining entropy sources, which we're working on in 90C, but I don't think it made it into the current out-for-comment draft.  

> 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".

All three 800-90 documents are out for public comment right now.  If you want to make sure it's included in the official comments (which we will definitely be going through and addressing), email exactly what you did here to RBG_Comments at nist.gov

More broadly to everyone: If you see problems with how the FIPS validation process plays with the DRBGs, or other problems, email a formal comment in.  

--John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20131029/2df0bf12/attachment.html>


More information about the cryptography mailing list