Re: [PATCH v2 00/25] Multiple changes to crypto/ansi_cprng.c

["George Spelvin" <linux@horizon.com>]

> If you look into other X9.31 implementations, you see that the DT vector 
> is a time stamp (even sometimes initialized to just 0 or 1) and then 
> incremented each time. Thus, you get "some form" of a counter mode for 
> the AES core.

I'm not saying you're wrong, but that still seems to me an extremely
contrived interpretation.  You're right that the tick rate isn't specified
and "once per call" isn't unambigously forbidden, but the plain reading
of the spec calls for a clock, not a counter.

> But of course, you could update DT with time stamps, provided you can 
> prove that they are monotonically increasing. 

I don't even see a need for that, although I could easily do it (by
adding get_random_int() rather than replacing).  I thought the goal was
that they were non-repeating, so short cycles are impossible.

>> You will agree, I hope, that the result from get_random_int *does*
>> include the entropy of a high-resolution timestamp?  Which is
>> cryptographically equivalent to including the unobfuscated timestamp?

> get_random_int does provide entropy, but my gut feeling (I have not done 
> measurements) is that it is in the range of maybe 2 / 3 bits per 
> invocation.

You said you didn't want to start a conversation about entropy, remember?
:-)  So I'm not discussing the issue, but please don't interpret that
as conceding anything.

As I said, it doesn't matter; my goal is just to do what the spec asks
for, as faithfully as possible without introducing any stupidities in
the process.

>> Which is why I'm trying to follow the spec as precisely as possible.

> If you only look at the regulatory side, then you must be aware of 
> SP800-131A applicable at least to the US side. X9.31 is sunsetted by the 
> end of 2015 and even not FIPS 140-2 certifiable any more for new 
> validations.

Well, if nobody wants it, why not simply rip it out?

I'm assuming there are other requirements documents that refer to
those documents, and haven't been updated to reflect tha changes.

That's what tends to happen: requirements flow downstream over
a period of years.  NIST may change its mind, but my contract
hasn't noticed yet.

I know this from personal experience: I've had frustrating discussions
about a "too hard to change" requirement for 1024-bit DSA *and* FIPS
140 certification.