RNG quality verification

Peter Gutmann pgut001 at cs.auckland.ac.nz
Thu Dec 22 19:31:11 EST 2005


Victor Duchovni <Victor.Duchovni at MorganStanley.com> writes:
>On Thu, Dec 22, 2005 at 10:28:47AM +0100, Philipp G?hring wrote:
>> I think the better way would be if I had a possibility to verify the quality
>> of the random numbers used in a certificate request myself, without the
>> dependence on the vendor.
>
>This is impossible. You don't see the raw "random" inputs: the CSR does not
>disclose the input primes, it only discloses their product. The real problem
>is deeper: there is no such thing as a single number that is or is not
>random, a random *process* produces the same discrete outputs as a similar
>non-random process.

This question may be solveable, but to do it you need to step back and look at
who's set this requirement and why.  I've run into the random-number-obsession
a couple of times, generally when government agencies or government
departments following policy set by government agencies are involved (example:
The CA generates the keys for the user and emails them their private key,
because we can't trust the quality of the user's RNG).  The reason I label it
an obsession is because the entire remainder of the keygen process can be
arbitrarily insecure as long as the RNG is some sort of officially approved
one (in fact in at least two cases the officially approved RNGs were quite
dubious).  So if this is merely a checkbox requirement then it can be met by
including an attribute in the request saying that the RNG was FIPS-certified,
and recording during the issue process that the request stated that it used an
approved RNG.

Easily solveable bureaucratic problems are much simpler than unsolveable
mathematical ones.

Peter.


---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list