No matter how good your algorithm and key sizes are, a bad random number generator means your cryptography will fail.  Only a hardware Random Number Generator (RNG) is a true RNG.  Software based “RNGs” are called Deterministic Random Bit Generators (DRBGs) because at some point they will repeat.  If you are designing a product, then you need to include a hardware based RNG such as Cavium, ACT2Lite, or another similar hardware processor that creates entropy.  Basically the entropy is created by the processor, conditioned via a hash function and seeded into the DRBG such as CTR_DRBG (AES), HMAC_DRBG (any), AES Hash_DRBG (any) according to NIST SP800-90A Rev 1 (ISO/IEC 18031:2011).  CTR_DRBG (AES) is recommended.

Avoid: DUAL_EC_DRBG and ANSI X9.31 using AES

Dual_EC_DRBG is the DRBG that NSA paid RSA $10 million to make it the default RNG in the RSA BSAFE toolkit.  ANSI X9.31 doesn’t have a back door, but it does not provide perfect forward secrecy (PFS) or backtracking resistance.  If a product does not do backtracking then an attacker can compute earlier random numbers and decrypt earlier encrypted documents.

If you don’t have a processor that also performs hardware based entropy, then use /dev/urandom with truerand.c pulling random data from the clock variance between the real time clock and CPU clock.  The normal entropy gathered from /dev/urandom on linux gets it from mouse clicks, disk controller, and other movements and sounds that have human interaction.  The problem is human movements are not random, so this form of entropy is low meaning not very random.  Using truerand.c provides a better entropy source that can be conditioned (SHA-1) and seeded into the DRBG.