Re: [kmip] KMIP: RNG Proposals

[Tim Hudson <tjh@cryptsoft.com>]

Thanks for the feedback Peter - and clearly the background from how we
came to this approach isn't clear to those who weren't involved so more
details need to be added.
It is good to get that feedback. Responses on the specific items are inline.

On 12/12/2013 12:59 PM, Robinson, Peter (RSA Engineering) wrote:
> I have reviewed the RNG / PRNG proposals and have the following comments and questions.
>
> kmip-rng-base-wd01:
>
> RNG Parameters: Some of the parts of RNG Parameters are optional, depending on the algorithm. We should specify which parts are expected for which algorithm.

The parameters are optional as the implementation may or may not know or
want to provide that level of detail. It allows for as much information
as is used in FIPS140 validation to be able to be provided but does not
preclude less information. It also allows for providing details as to
the cryptographic building blocks in RNGs independent of the particular
- allowing a client to be able to see if there is something that it
wants to be able to make a decision on acceptability based on that
information. There isn't a fixed list and they are also optional for
that reason. If you want to see examples of common usage then the RNG
validation list is the right starting point.

> Cryptographic Length: This needs to be defined. What is it for which algorithm? Is it the perceived security strength? That is, for HMAC DRBG 128 bit security strength, should this be 128? For EC DRBG using a P256 curve should this be 128 or 256?
Cryptographic Length is a well defined attribute. And in this context is
the the length of the corresponding Cryptographic Algorithm that is
being used as a building block. It is not the perceived security
strength - that would be a separate attribute to add - and one which
when discussed as a group lead to it not being included.

> DRBG Algorithm: We need to specify exactly which algorithms these are. I assume they are meant to be NIST's SP800-90 algorithms? If so, we should we be explicit.

They are explicitly listed. See the 9.1.3.2.38 DRBG Algorithm
Enumeration. It lists them there.

> DRBG Algorithms and RNG Algorithm Enumeration: I think it makes sense to combine these two enumerations and for us to have a single list of algorithms.
It doesn't make sense to combine them at all as there are groups of
classifications and specific algorithms within each group. This approach
was discussed and modelled of the most detailed specification of RNGs
available - that from NIST and the FIPS140 cryptographic module
validation program and worked through with the NIST representative at
the time. You should take a look back through the RNG validation lists
and look at the history of how NIST has approached their descriptive
terminology in this area (and they continue to expand on it).

> Recommended Curve: This should be Curve, indicating it is the curve which must be or has been used.
No it shouldn't. This refers to the existing concept within KMIP which
has always been called "Recommended Curve". That just happens to be the
approach that KMIP uses which you can debate whether or not that was a
good name to have picked back in KMIP 1.0 - but it is the name - and the
existing concept. All references to curves use this attribute.

> A common PRNG parameter which is not able to be specified in the current proposal is Prediction Resistance. This is the combining of one bit of entropy with each output bit. This can be on or off. This is discussed in detail in NIST's SP800-90a-rev1.
We haven't seen any NIST indication as yet that this will be included in
the RNG testing. It can be added if this is of interest and you see a
use case for it.

> It would be good to be able to indicate what entropy sources have been or will be used to seed a PRNG algorithm. Is it fair to assume that all PRNG instances in a server will be seeded with the same types of entropy sources, and as such could this be the same for all PRNG algorithms?

That is an interesting area for discussion - classification of the
actual entropy source - and something I think is a lot broader as an
area. To date no one has indicate that this is something which is of
interest - and NIST itself don't have a taxonomy for classification of
actual entropy sources. The assumption you ask about isn't one that is
valid to make from my understanding. It would be useful to get comments
from others. I think this whole area (entropy sources) is one the group
hasn't indicated an interest or a use case for tackling as yet.

Thanks,
Tim.