This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients christian.heimes, neologix, pitrou, vstinner
Date 2013-08-22.18:47:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <CAH_1eM1LG8EMf6qGNR++QeuOydYXF7Ph2tUwWc6rRTAcrJYMcw@mail.gmail.com>
In-reply-to <1377193524.1.0.750459467534.issue18811@psf.upfronthosting.co.za>
Content
> It doesn't look like OpenSSL's PRNG is much faster than /dev/urandom if
> Python keeps a persistent fd:
>
> $ python3.3 prng.py
> loops: 1000000
> bytes: 16
> /dev/urandom (fd)        1.2181
> os.urandom()             3.2892
> RAND_pseudo_bytes        1.2924
> RAND_bytes               1.2945

Except that your benchmark uses 4096-bytes buffering for /dev/urandom
with a persistent FD, which is not the case with the implementation
proposed in #issue18756. Without buffering (i.e. one read() syscall
per invokation), the numbers change:

$ ./python  ~/prng.py
loops: 100000
bytes: 16
/dev/urandom (fd)        1.37106
os.urandom()             1.4446
RAND_pseudo_bytes        0.83635
RAND_bytes               0.75604

Also, you use CLOCK_PROCESS_CPUTIME_ID which only accounts for CPU
time, not wall-clock time, but it doesn't change much.

> Some crypto experts also say that the PRNG of a stock OpenSSL build is sub
> par. The algorithm is neither standardized by NIST nor carefully developed
> by a cryptographer. FIPS builds of OpenSSL have a better PRNG.

That's an implementation detail, it could very well improve.

But I don't have a strong feeling, so if that's not deemed useful, I
won't take it personally :-)
History
Date User Action Args
2013-08-22 18:47:26neologixsetrecipients: + neologix, pitrou, vstinner, christian.heimes
2013-08-22 18:47:26neologixlinkissue18811 messages
2013-08-22 18:47:26neologixcreate