Re: [kmip] KMIP: RNG Proposals

[Tim Hudson <tjh@cryptsoft.com>]

On 13/12/2013 9:18 AM, Burns, Robert wrote:
> [<[Bob]>] I think that Peter is referring to the fact that NIST
> specify each DRBG as being instantiated with Prediction Resistance on,
> or off -- both/either of which can be tested. So I think if we are
> going to have attributes which represent the state in which the PRNG
> was used, then perhaps just an attribute flag indicating whether or
> not 'Prediction Resistance' was enabled should be sufficient. 

If the objective is to list all the possible testing options covered in
the validation suites then that certainly can be done but there is a lot
more than just prediction resistance which isn't currently modelled. At
the time the clear focus was to have enough information to make
decisions in the client and to indicate the building blocks being used.

For those who are not familiar with the area and want to read up on it
you should read through the following two NIST documents to get a
clearer idea as to the scope that would need to be addressed if we as a
group want to expand to cover that area in addition to what is currently
noted.

http://csrc.nist.gov/groups/STM/cavp/documents/rng/RNGVS.pdf
http://csrc.nist.gov/groups/STM/cavp/documents/drbg/DRBGVS.pdf

We went through that material before the original proposal was created
and it is an area I'm rather familiar with having taken multiple modules
through FIPS140-2 validation across multiple organisations. Listing all
the testing options will add another 6-12 fields within the RNG
Parameters structure.

On the entropy source approach, I too think that waiting and seeing
where NIST are going on that topic prior to tackling it is the sensible
approach, noting that we previously backed away from tackling that area
and settled on using the high-level elements from the NIST RNG concepts
as the base. The number of times NIST has proposed and the changed the
approach of how to handling entropy sources and how they are currently
handled within the FIPS140-2 context shouldn't be ignored in my view.

Again this all can be revisited if there is general interest in a
broader scope - but given previously we discussed this for KMIP 1.2 and
then backed it out of the proposals I'm cautious to repeat that same
process when ultimately it came down to insufficient member support to
commit to implementations that would actually exercise that sort of
functionality and a general consensus that tackling items in an
incremental fashion was the right approach to take.

It would be good to get the views from vendors who have taken modules
through validation (and from others) as to whether or not expanding the
scope to covering all the options within the validation suites is of
interest. If there is a general consensus then I can certainly update
the base proposal to include additional fields.

Thanks,
Tim.