Slashdot Mirror
NIST Updates Random Number Generation Guidelines
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.
One of they few poorly understood concepts in software development is that improperly initialized (called seeding) DRBG will break your crypto.
/dev/random for seeding. You want it to block if not enough randomness available.
For Linux, and especially for headless systems, use
They're more like guidelines anyway.
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.
Why do so many systems still use the hashed root or admin password to seed tcp sequence numbers? Cisco, Sun, IBM and DEC all started doing it about the same time. So who suggested it to them and just how many groups know how what it takes to pull bits out of that hash?
From a code approach it's pointless, because the physical simulation would run exactly the same each time. Unless your randomize various factors such as for example, the release time of the balls, the speed the wheel which "mixes" them up. However, for this approach to work, you still need your underlying random number generator to already be working to generate the randomization required by the physics engine. And at the end of it all, you're putting a whole lot of effort into a limited entropy randomization system when you could just use a couple of dedicated algorithms to achieve a much greater result.
From a device point of view, yes - this is basically what hardware random number generators are. There are lots of different ones out there that use different factors such as background radiation, RF noise, plasmas, etc, to create a non-reproducible value. Most of them are pretty good at what they do, and while some may be "better" than others, the differences in the degrees of entropy they produce are largely academic - almost any of them will do the job.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
I agree. The outcome from lottery machines is way too predictable and that's why I'm a billionaire having never worked a day in my life.
NIST recklessly broke our trust in them by allowing known to be broken encryption into their standard. Their new document may come with all the best intentions, but it will take years to rebuild that trust. Let's wait for what the crypto community has to say about these documents, before we blindly follow their latest standards.
Thank you a thousand times to the link to the handbook! Now I can ditch the boring William Stallings crypto book which I never finished AND I don't need a physical copy!
To find out where the NSA put the twist.
Religion is what happens when nature strikes and groupthink goes wrong.
Lucky for us, Diffie-Helmann requires a random sources on each side. If your RNG is broken and your counter-party's isn't, you're still good.
Religion is what happens when nature strikes and groupthink goes wrong.
https://xkcd.com/221/
Your reading comprehension needs some work.
"The true measure of a person is how they act when they know they won't get caught." - DSRilk
The Yarrow algorithm, or its progeny Fortuna, are not yet a thing?
Shame.
https://en.wikipedia.org/wiki/...
Kriston