[Cryptography] SP800-90A B & C

[dj at deadhat.com]

> On Nov 10, 2013, at 4:22 PM, David Johnston <dj at deadhat.com> wrote:
>
> ...
>> Some of my comments were about the way the spec and FIPS make it hard to
>> add multiple sources. I would like to enable users to add their own
>> trusted sources so they can ensure randomness is robust.
>
> There are two separate issues here:
>
> a.  Allowing additional input that's not credited with entropy, but which
> may add security.
> b.  Allowing the combination of two or more approved, validated entropy
> sources.
>
> I'm still not sure where we run into problems with (a) (there's some 140-2
> guidance that requires callers of RNGs to be authenticated at higher
> validation levels--that may cause problems), and at least so far I don't
> have an actual example of a FIPS lab refusing to allow a 90A DRBG to use
> additional input from an off-module unauthenticated source, (if you have
> one, please let me know) but I think this is something we can address in
> guidance on 90A.
>
> Dealing with (b) is going to have to wait for 90C to be finished.  It's
> relatively easy to allow this for entropy sources that live within some
> kind of separate boundaries, but not for entropy sources that have access
> to the same physical processes or internal state.  But combining
> independent entropy sources is something that should make it into 90C.
>
> As an aside, most of the content of 90A, B, and C *did* go through a
> normal standardization process in X9F1.  And since then, we've had a
> public workshop and a couple rounds of public comment, trying to hammer
> out things that might cause problems.  So I'm not sure if this is a normal
> standards process, but it sure is allowing for a fair bit of public
> comment.
>
> --John
>

A normal standard process puts out a draft, invites comments and has a
standards body vote on the proposals in the comments.

The the process iterates. But in each iteration, the parts of the document
open for technical comment is limited to unresolved comments, things that
changed and obviously broken things.

This iterates until there are no comments left.

Then the whole document is opened up for comment again and the process
repeated 1 or 2 more times.

This is a very effective way of getting consensus in a specification and
making the process work on a cadence with which people can align their
product developments.

NIST seems to operate by
1) Writing a document
2) Inviting comments
3) Updating the document and stamping it as done.

So we all end up with an inadequately reviewed document which no one is
happy with. Check out the RNG discussions on this forum. What educated
people want looks nothing like what SP800-90 offers. Those of us
implementing to SP800-90 and FIPS run into issues that have to be argued
out with the certification lab and have to be designed around in ways that
do not enhance security.

The no-inputs to meet FIPS140-2 + SP800-90 issue is real. We were not told
"You can't do that". We asked for guidance because the problem was evident
and in discussion with the certification house the options, everyone
agreed that the "no inputs" solution would meet both specs. No one was
misinterpreting a spec. The conflict is there for everyone to see. I can
name names in private, but I'm not pointing a finger at the certification
lab. The problem is in the spec.

How the 4.9.2 issue come into being is beyond my comprehension. Why is it
there? What were they thinking?

During the ongoing development of SP800-90, new math and new algorithms
have comes out that change the playing field. Compliant solutions are
locked out from benefiting and users are therefore locked out from the
security benefits, which with RNGs lay mostly in greater deployment, since
the biggest problem with good TRNGs is their absence on computers which in
part is related to the heavy resource load of SP800-90 solutions.

I haven't seen a lot of comments in SP800-90B&C. I didn't see my previous
sets of comments get published in the last two rounds. Am I missing other
people's comments? It's necessary to be able to see all the comments in
order to converge on consensus and learn from each other.

We've got chips going out the door and the spec is still subject to
change. As I stated in a recent presentation "This is not a standards
process one can love".