1
$\begingroup$

I've read the Chapter "Randomness" from the Serious Cryptography book and it raised some questions. Namely:

It is written that Mersenne Twister is proved to be cryptographically irreliable. And that is it used by some languages, especially by Python. I have seen a lot of project with different languages when secure random stuff (like keys, token, sessions and so on) were generated just by taking random bits from a standard library.

I have not seen a situation when someone takes care of entropy level.

How to know that generating (pseudo) random keys is secure? Especially, I don't see implementation of pseudorandom generator that return error (for example when entropy is not sufficient). Could tell me something about my doubts and recommend me any book/article that covers that subject more specifically.

Improve this question
$\endgroup$
2
  • $\begingroup$ You have to make sure you are taking from a secure source if you want unguessable values (e.g. for a key). How that is done depends entirely on the language. $\endgroup$
    – forest ♦
    Sep 28, 2018 at 10:39
  • $\begingroup$ The GPG program (github.com/gpg/gnupg) takes care of entropy in the way you allude to, the user is required to wait/generate 'random noise' until the program has determined a sufficient amount of entropy is available for key generation. $\endgroup$
    – Chris
    Sep 28, 2018 at 11:29

1 Answer 1

Reset to default
1
$\begingroup$

First, If the source isn’t explicitly labeled as “secure” or “crypto” in its name, you must assume it is insecure.

For example, in C#, the System.Random is insecure while System.Security.Cryptography.RandomNumberGenerator is obviously intended to be a secure RNG.

Second, you’ll need to actually do some research to ensure that it is, in fact, going to be a secure RNG in the version you are using, and in the target deployment environment. Will you have an entropy source when it is deployed?

Most languages let you access the operating system’s secure RNG in some way; these should be preferred over any user-space generators to ensure fork()-safety. User-space RNGs are also far more likely to have bugs or their state compromised by bugs in user-space applications, which history shows are innumerable.

For example, Pythons os.urandom() doesn’t mention security in its name, but it does call the operating systems secure RNG directly (/dev/urandom on Linux and CryptGenRandom on Windows). When you use the OS generator you also don’t need to evaluate the security of a particular language’s generator user-space algorithm choices or implementation quality.

The OS generator on any recent mainstream OS can be trusted, unless you’re deploying into an environment with no entropy source (such as an embedded Linux device with no user inputs and no hardware RNG).

Improve this answer
$\endgroup$
10
  • $\begingroup$ "The OS generator on any recent mainstream OS can be trusted" is wildly overoptimistic. Here's a recent serious bug, and history is badly repeating itself on that one. The software of the OS could be rigged. The hardware could be rigged (e.g. with a JTAG probe). VMs are a thing... $\endgroup$
    – fgrieu ♦
    Sep 28, 2018 at 12:20
  • $\begingroup$ @fgrieu What is one supposed to do in that situation to solve the problem? $\endgroup$
    – Ella Rose
    Sep 28, 2018 at 13:54
  • $\begingroup$ @Ella Rose: Try hard to know your hardware, and be as sure as possible that it runs the software you think it runs. For critical things, mix entropy sources using something carefully reviewed that demonstrably is secure if any of its source is secure. Do include the OS (e.g. /dev/urandom or CryptGenRandom) as one of these. Ideas for the rest include clock_gettime or GetSystemTimeAsFileTime, hash of wmic process output, and values of RTDSC or QueryPerformanceCounter before and after gathering that. A comment is too small for all my tricks, and I'm reluctant to reveal them all. $\endgroup$
    – fgrieu ♦
    Sep 28, 2018 at 14:22
  • 1
    $\begingroup$ @fgrieu a user-space CSPRNG is not going to save you from a backdoored OS or hardware. It is, however, a lot of added complexity that is easy to screw up. Critical Bugs in user space RNGs far outnumber those in kernel RNGs if you look at CVEs. User-space RNGs are still subject to all the dangers of early boot, little physical entropy, and VM cloning. But they add the more serious dangers of forking and access control to the state. How is that good for security? $\endgroup$
    – rmalayter
    Sep 29, 2018 at 1:29
  • 1
    $\begingroup$ @Swashbuckler: is the OS is compromized, we are toast anyway. But if the OS only has an accidentally flawed RNG (which has happened times and times) then adding in other sources of entropy can save the day. $\endgroup$
    – fgrieu ♦
    Sep 29, 2018 at 19:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.