Slashdot Mirror

← Back to Stories (view on slashdot.org)

NIST Updates Random Number Generation Guidelines

Posted by Soulskill on from the of-barn-doors-and-horses dept.

An anonymous reader writes: Encryption weighs heavily on the public consciousness these days, as we've learned that government agencies are keeping an eye on us and a lot of our security tools aren't as foolproof as we've thought. In response to this, the National Institute of Standards and Technology has issued a formal update to its document on how to properly generate a random number — crucial in many types of encryption. The update (as expected) removes a recommendation for the Dual_EC_DRBG algorithm. It also adds extra options for CTR_DRBG and points out examples for implementing SP 800-90A generators. The full document (PDF) is available online.

3 of 64 comments (clear)

  1. Bad RNG will make your crypto predictable by sinij · · Score: 4, Interesting

    One of they few poorly understood concepts in software development is that improperly initialized (called seeding) DRBG will break your crypto.

    For Linux, and especially for headless systems, use /dev/random for seeding. You want it to block if not enough randomness available.

  2. Randomness can't come from a computer program by Bruce+Perens · · Score: 2, Interesting

    True randomness comes from quantum mechanical phenomena. Linux /dev/random is chaotic, yes, enough to seed a software "R"NG. But we can do better and devices to do so are cheap these days.

    I wouldn't trust anything but diode noise for randomness. If I had a need to transmit messages privately, I'd only trust a one-time pad.

    --
    Bruce Perens.
    1. Re:Randomness can't come from a computer program by Anonymous Coward · · Score: 2, Interesting

      OneRNG - An Open and Verifiable hardware random number generator -- relevant talk from Linux.conf.au 2015. It uses diode and (optionally) RF noise to generate a stream of high-quality entropy which couples directly to the kernel.

      They touch upon a concept that I believe many admins should be aware of: if you do mass-deployment of machines, this might very well include generation of e.g. SSH keys. The problem is if the keys are generated in such an early stage that the random pool has not been able to be readily distinguished from other machines within the deployment. This might open up the possibility for an attacker who has knowledge about a less privileged machine within such a deployment to attack machines which in a later state got more important roles.

      I have even seen situations where companies have created images with pre-generated cryptographic signatures, making all machines within a deployment hold the exact same secret information...