On Wed, May 25, 2011 at 3:52 AM, Terry Reedy <tjre...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
