Re: [dsfjdssdfsd] Any plans for drafts or discussions on here?

[Paul Hoffman <[e-mail]>]

On Jan 22, 2014, at 12:29 PM, Dan Harkins <[e-mail]> wrote:

> On Wed, January 22, 2014 11:16 am, Paul Hoffman wrote:
>> On Jan 22, 2014, at 10:40 AM, Dan Harkins <[e-mail]> wrote:
>> 
>>> To minimize the possibility of someone borking their DRBG
>>> implementation
>>> we can include some test vectors-- instantiating with A produces state
>>> of
>>> B; reseeding of state B with C produces state D; generating with state D
>>> produces E, etc.
>> 
>> If we could be sure that there was no way for the mechanisms needed to
>> test those vectors could possibly appear in an implementation, that would
>> be great. If we can't be sure of that, we are proposing an implementer
>> include something that could cause a catastrophic failure if those inputs
>> are accidentally left in.
> 
>  That seems like an absurdly high bar-- that there is no way someone
> could so something demonstrably stupid. We use test vectors when
> specifying things like HKDF or AES-<pick your mode> and no one
> seems to generate a function that only accepts those inputs and only
> produces the specified outputs.

Note the difference with "HKDF or AES-<pick your mode>" and a DBRG. In the former case, if they only accepted the test vectors for input, they would never interoperate. In the latter case, if they only accepted those inputs, they generator would still work just fine; it would also be completely predictable.

> I really don't think people will suddenly
> start  hard-coding test vectors into code now.

They already frequently do exactly that. I have seen multiple implementations have a FIPS 140 self-test mode built in.

> 
>> Regardless, that's not what Don's draft does.
> 
>  I'm still hoping that an Informational RFC on a good DRBG will be
> generated.

In your mind, who is the intended reader? Implementers of the good DRBG in an OS, or in an application, or both?

>>> The more people that implement anything will increase the probability
>>> of
>>> a broken implementation somewhere, I definitely agree. But it is an
>>> accepted
>>> economic truth that relying on a single source for anything is a bad
>>> idea.
>> 
>> That seems like a strawman: who says that there is a "single source" of
>> ideas for how to implement randomness? Three large server OSs (Linux,
>> FreeBSD, Windows) all do it differently.
> 
>  The single source is "your OS".

Ah, got it. Are you saying "if you are going to re-implement crypto primitives and not trust your OS, and one of the ones you are re-implementing is the DBRG, here is a best practice for how to do it"?

> While there are 3 large server OSs, there
> is no single application that can obtain randomness from all three since
> there is no application that runs on all of them (and my experience is
> that a single linux application won't necessarily work from version X of
> the OS to version Y-- hell, sometimes the source won't even compile).
> 
>  And you know, the "if we could be sure there was no way…" thing works
> both ways, especially regarding a large (monopoly) OS whose track
> record on security and code quality is not perfect.

Fully agree. We should definitely not say "X is a best practice for DBRG" where X is a single value.