Re: Is ansi_cprng.c supposed to be an implmentation of X9.31?

[Stephan Mueller <smueller@chronox.de>]

Am Samstag, 29. November 2014, 14:32:05 schrieb George Spelvin:

Hi George,

>>> Other than enough implementation stupidities to make me scream
>>> (particularly the "rand_data_valid" variable name which is actually
>>> a
>> 
>> Its actually a counter of the number of valid random data bytes in
>> the buffer being returned to a caller, as well as an index into the
>> internal buffer from which to draw fresh random data.  Sorry if you
>> don't get that, but it seems pretty clear.
>
>As you can see, I ended up choosing less abrasive wording in the
>version I *thought* was public; this got launched into the void while
>in draft form. Sorry about that.
>
>Oh, its use as an index into the read_data array is clear enough;
>it's just that the fact that the number of valid bytes in that
>array is DEFAULT_BLOCK_SZ - ctx->rand_data_valid seems "obviously
>backward" to me.
>
>You'd think "ctx->rand_data_valid = 0" would mean "no data is valid;
>force update cycle next access", but nope...
>
>> is that this is definitely NOT conformant with the X9.17/X9.31 spec.
>> 
>> This is the document it was based of off:
>> http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf
>
>Ah, I actually read that, but I didn't remember that the "Based on"
>wording is a direct quote.
>
>If you go to the original ANSI specs (which I've read in the past,
>but din't have a web-accessible copy to link to), they're a bit
>more explicit on the point.
>
>> Please read more closely, the header clearly states this is a PRNG
>> implementation, and a quick google search of the terms in the header
>> bring up the document referenced above, with which this cprng is in
>> compliance with.
>Yes, it was quite clear that a strict reading of the comments said that
>it was a PRNG, but I lost track of the fact that "Random Number
>Generator Based on ANSI X9.31 Appendix A.2.4" was NIST's wording that
>was being quoted, and was left with the impression that compliance to
>the ANSI spec (which *does* call for a high resolution timestamp) was
>being implied.
>
>I either wanted to provide the implied compliance or clarify the
>absence of it.
>
>> Sure, knock yourself out.  I don't consider it more or less valid to
>> do so, but patches are welcome.
>
>Coming right up!
>
>> Definately keep the ability to support external setting of DT, as you
>> can't pass any validation tests without it.
>
>Yes, I've already figured that out when studying the impact of such a
>change.  Since there's already special-case handling of with/without
>a DT vector, that seemed the obvious thing to hook into.
>
>The two changes that affected callers, which I didn't feel very
>confident about my understanding of, were:
>1. Changing the recommended seed size, and
>2. Using actual random seed material.
>
>The other one, which I have to think *very* hard about, is whether
>using the same seed material as /dev/random in this much weaker
>cryptographic construction will introduce a flaw in *it*.

I have no idea what you are referring to here. The caller is requred to 
seed the DRNG. Typically that is done with a call to get_random_bytes. 
As Neil mentioned, the X9.31 DRNG implementation does not seed itself.

The get_random_bytes call has no relationship to /dev/random other than 
it pulls from the same noise source. It is highly related to 
/dev/urandom as it uses the same entropy pool and is nonblocking.

I would be very interested in cryptographic or entropy related concerns 
about this seeding approach.


Ciao
Stephan
--