Randomness

Good randomness is at the center of cryptography. It is used to generate keys, IVs, nonces, etc.

Is Dual EC a good algorithm?

No.

Are the NIST PRNGs secure?

Yes, but they suck.

Is math/random a good package to generate randomness?

In most languages, any math/random packages or libraries will offer APIs to generate non-cryptographically secure randomness. These libraries are not to be used to generate randomness for security purposes.

Can I trust any Random Number Generators or Prime generation implementations?

Yes and no. Historically, people have done very stupid things.

• 2008 - Debian OpenSSL PRNG bug. Resulted in a lot of SSH keys being weak
• 2010 - PS3 ECDSA leak the key - The randomness needed for ECDSA to work was bad, leaking the ECDSA keys of the PS3.
• 2012 - Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network Devices - weak RSA keys
• 2012 - Ron was wrong, Whit is right - "two out of every one thousand RSA moduli that we collected offer no security"
• 2014 - Private Key Recovery Combination Attacks: On Extreme Fragility of Popular Bitcoin Key Management, Wallet and Cold Storage Solutions in Presence of Poor RNG Events -
• 2017 - Infineon RSA prime generation bug - millions of security keys impacted.
• 2019 - Biased Nonce Sense: Lattice Attacks against Weak ECDSA Signatures in Cryptocurrencies
• 2019 - U2F ECDSA vulnerability - "The firmware code used incompatible transfer instructions when passing a critical secret value to the cryptographic hardware block, resulting in generating secret values of a specific structure and having a significant loss of entropy in the secret value (64 bits instead of 256 bits)"

linux: /dev/random vs /dev/urandom

• short answer: use getrandom()
• long answer: use /dev/urandom unless you really care about good entropy at boot time.

Early during boot, it is possible that /dev/urandom is in a state where it is not properly seeded. getrandom() blocks if this is the case, but /dev/urandom doesn't and might return weak random numbers.

How to obtain randomness on Windows?

• CryptGenRandom is said to be deprecated, but realistically it will probably never be.
• the new API is BCryptGenRandom from the Cryptography API: Next Generation (CNG).

What's better? A kernel or a user-land PRNG?

• short answer: kernel PRNGs are better.
• long answer: kernel PRNGs can be slow, because they are exposed as a system call. In situations where randomness generation is the bottleneck, it might be desired to use a userland PRNG and seed it with the kernel PRNG.

Using a userland PRNG has its caveats:

• if a process forks, the parent and the child will have the same PRNG state (and thus derive the same random numbers).
• if they use the PID to differentiate their state, then forking enough time might wrap the PID and force two process to have the same PRNG state.
• snapshoting a VM and restoring from it several times will produce several instantiation of the same PRNG.

Are UUID randoms?

Yes, but not really. Underneath the surface, they are usually generated by using an actual cryptographically secure PRNG, so don't take shortcuts and use a cryptographically secure PRNG directly.

Is RDRAND secure?

Nobody knows, but it does solve the problem of not having good sources of entropy in headless devices. In general, a sane operating system does not rely solely on RDRAND to seed its PRNGs, and so you should be safe. In practice, if you are really paranoid, I suggest supplying additional entropy to your device

How long should a random string be to avoid collisions?

• The short answer: 256 bits
• The long answer, use this tool