[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [kmip] KMIP: RNG Proposals
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 126.96.36.199.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.