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:]
> Sent: Thursday, December 12, 2013 6:58 PM
> To: Burns, Robert
> Cc: Robinson, Peter (RSA Engineering); ; 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.
>
