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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> - the non-determinism you get from get_random_int is very weak. If you start
> thinking about the information theoretical entropy behind that function that
> is used once in a while, you may not get much entropy. Please, please, please,
> I do not want to start a discussion around entropy -- I will not participate
> in such discussion :-)

I could have such a discussion, but there's no need to; for the most part,
I agree with you.  I wasn't trying to design a *good* RNG, I was trying
to comply slavishly with what X9.17, X9.31, and the NIST specification
call for: a timetamp.

To quote http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf,
section 3:

# Let DT be a date/time vector which is updated on each iteration. 

That's what I was trying to produce, nothing more and nothing less.

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?

> Thus, I am questioning whether such slightly non-deterministic RNG would be 
> used.

As far as I know the only reason to *ever* use ansi_cprng is for
regulatory/certification reasons.  It's not horrible, but it's definitely
been superseded, by the NIST SP800-90A generators at least.

Which is why I'm trying to follow the spec as precisely as possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux