RE: [kmip] KMIP: RNG Proposals

Tim,

I was merely responding to your comment on Peter's recommendation to support prediction resistance, which was: "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.".

I found your assertion about NIST not including it in the RNG testing curious, (to say the least), so I thought I'd chip in and try to clarify. Obviously, my response missed the mark.

Regarding your second sentence in your response above, I would like to indicate that *if* we are adding attributes at this time, then it is indeed of interest to me – the mere fact that NIST actually includes this attribute on the algorithm validation certificate is reason enough to make the attribute available, IMHO. I am *not* advocating adding every testing attribute or making any other changes; just stating that I do see the value in the ‘prediction resistance’ attribute on a NIST SP800-90(A) DRBG object.

Bob

> -----Original Message-----

> From: Tim Hudson [mailto:tjh@cryptsoft.com]

> Sent: Thursday, December 12, 2013 6:58 PM

> To: Burns, Robert

> Cc: Robinson, Peter (RSA Engineering); kmip@lists.oasis-open.org; Carielli,

> Sandra; Pingel, Stefan; Brown, Jaimee; Furlong, Judith; Griffin, Robert

> Subject: Re: [kmip] KMIP: RNG Proposals

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

kmip message