[Python-Dev] [Python-checkins] cpython: Issue #12049: Add RAND_bytes() and RAND_pseudo_bytes() functions to the ssl

[Nick Coghlan]

On Wed, May 25, 2011 at 3:52 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 5/24/2011 12:06 PM, Victor Stinner wrote:
>> An important feature of a CPRNG (cryptographic pseudo-random number
>> generator) is that even if you know all of its output, you cannot
>> rebuild its internal state to guess next (or maybe previous number). The
>> CPRNG can for example hash its output using SHA-1: you will have to
>> "break" the SHA-1 hash (maybe using "salt").
>
> So it is presumably slower. I still do not get RAND_pseudo_bytes, which
> somehow decides internally what to do.

The more important feature here is that it is exposing *OpenSSL's*
random number generation, rather than our own. A CPRNG isn't
*necessarily* slower than a non-crypto one (particularly on systems
with dedicated crypto hardware), but they can definitely fail to
return data if there isn't enough entropy available in the pool (and
the system has to have a usable entropy source in the first place).

The RAND_bytes() documentation should probably make it clearer that
unlike the random module and RAND_pseudo_bytes(), RAND_bytes() can
*fail* (by raising SSLError) if it isn't in a position to provide the
requested random data.

The pseudo_bytes version just encapsulates a fallback technique that
may be suitable in some circumstances: if crypto quality random data
is not available, fall back on PRNG data instead of failing. It is
most suitable for tasks like prototyping an algorithm in Python for
later conversion to C, or similar tasks where it is desirable to use
the OpenSSL PRNG over the one in the random module.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia