# Is Pseudo-Random Generator (PRG) in OpenSSL uniformly distributed?

I need to know can we use PRG of OpenSSL as a PRF?

• Have you already looked up which PRG is being used? If so, care to share? If not - why? – Maarten Bodewes Feb 12 '15 at 20:16

Yes, the Pseudo Random Number Generator (PRNG) in OpenSSL is Cryptographically Secure, which means it passes statistical tests, but as @Maarten Bodewes suggests in his comment, why not go one step further and use that PRNG directly, rather than through OpenSSL?

OpenSSL can use EGD (which stands for Entropy Gathering Daemon). It is a process that taps into configurable entropy sources in a given system to provide cryptographically secure random numbers. EGD is actually modeled after /dev/random in *Nix Operating Systems, so it would not be available in a Windows system, for example, but its function is the same as /dev/random which is to gather entropy for random number generation.

If you are creating an application in a *Nix system (OS X, Linux, etc) chances are that EGD is taking input from /dev/random, so your best bet is to use it. If you are in a different OS, then EGD is probably the way to go.

• +1 Security Aficionado: Does EGD prevents against a poor entropy for seeding? You're conscient that the process is deterministic. – Robert NACIRI Feb 12 '15 at 23:14
• @sesurity Aficionado: Thanks for your answer. In the first paragraph of your answer, you said "why not go one step further and use that PRNG directly", I'm wondering what you mean by using it directly? – user13676 Feb 13 '15 at 10:43
• @user13676 Sorry, I was making assumptions about what you were developing. If you are using C or another low level language, you can access /dev/random directly, but if you are using a scripting language, it might make more sense to use OpenSSL bindings. You can skin this cat in many ways :) – Security Aficionado Feb 13 '15 at 14:01
• "Cryptographically Secure, which means it passes statistical tests". To be clear (and I don't mean to imply Security Aficionado is unaware of this issue), Cryptographic security requires much more than that. Standard statistical tests are quick and dirty, and look for very generic types of "non-randomness"; cryptographic security requires outputs to be indistinguishable from random even against computationally intensive tests that are targeted specifically at the algorithm in question. – Seth Feb 13 '15 at 19:08
• EGD is not platform-independent. OpenSSL actually allows configuring its PRNG, but defaults to an internal one that uses an iterated hash and is seeded in platform dependent ways: on Unix pid, time, and /dev/{,u,s}random if available otherwise EGD if available; on Windows a bunch of system stuff and CryptGenRandom if available; on older systems other ways I haven't looked at. – dave_thompson_085 Feb 13 '15 at 21:47

Security analysis of "Nix /dev/random" is discussed here

"Security Analysis of Pseudo-Random Number Generators with Input: /dev/random is not Robust", by Yevgeniy Dodis, David Pointcheval, Sylvain Ruhault, Damien Vergnaud, and Daniel Wichs. http://eprint.iacr.org/2013/338.pdf

With an interesting blog https://www.schneier.com/blog/archives/2013/10/insecurities_in.html

then it might be wise to reconsider the blind usage of /dev/random as suggested in the first response.

OpenSSL API for PRNG (FIPS version) is https://www.openssl.org/docs/fips/UserGuide-2.0.pdf section 6.1.1 . The entropy callback is under application responsibility. You might not wish to use the dual EC-DRBG implementation (section 6.1.2) because of perceived vulnerability. The section about "default DRBG" explains how to map RAND_xxx functions to a FIPS approved DRBG.

You can rely on OpenSSL RAND_xxxx calls after you verify the following points

• which DRBG is instantiated (either by default, either overriden)
• where the functions rand_seed_cb() and rand_add_cb() get their entropy in your implementation.

If the initialization sequence instantiates the DRBG block based on AES-CTR, seeded and re-seeded with /dev/random, then the PRG of openSSL would satisfy the criteria for an acceptable PRF for cryptography.

Many academic papers mention that the output of AES is indistinguishable from randomness. and this is already answered Is it possible to distinguish a securely-encrypted ciphertext from random noise? .

(edited to smooth 'strong' statements as suggested in comments)

• You needn't worry about DualEC_DRBG in OpenSSL. Due to an absolutely karmic bug, it passed the FIPS validation tests but failed if you tried to use it in an application. This wasn't discovered until Snowden caused people to test it; there had been no bug reports from real users in the years in between, although there might be some users who wouldn't be willing to report publicly. Due to the over-rigid FIPS140 rules, the bug couldn't be fixed even if anyone still wanted this working, so it's simply been removed from the validation. In addition to the fact NIST no longer recommends it. – dave_thompson_085 Feb 13 '15 at 21:54
• @dave : I only mention "perceived vulnerability" thinking about the magic numbers used as generators in NIST ECC recommended curves. It is well known that FIPS tests are targeting conformance and interoperability, and are not designed to validate correctness, coverage, corner cases .... So bugs can be part of a certified product, and I do not worry about them, they tend to be discovered and fixed over time. Thanks for reviewing my answer and for your comment. – Pierre Feb 13 '15 at 22:23
• Two items on this response: 1) The question is about the distribution of the PRNG, not its strength, and 2) the paper you quote says "it remains unclear if these attacks lead to actual exploitable vulnerabilities in practice" which is still the case today. It is misleading to suggest that it is unsafe to use a PRNG that most people use today through OpenSSL. – Security Aficionado Feb 13 '15 at 23:38
• The question I read is "I need to know can we use PRG of OpenSSL as a PRF?" . It is extremely complex to guess remotely which DRBG is instantiated, and I provide the links to the callbacks and hooks in openSSL. I do not discuss the strength nor the distribution of a sp800-90 compliant implementation. If the initialization sequence instantiates the DRBG block based on AES-CTR, seeded and re-seeded with /dev/random, then the PRG of openSSL would satisfy the criteria for a crypto acceptable PRF. I complete my answer that way. – Pierre Feb 14 '15 at 2:47