NIST Updates Random Number Generation Guidelines 64
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.
Bad RNG will make your crypto predictable (Score:5, Interesting)
For Linux, and especially for headless systems, use
Re: (Score:2)
Re: (Score:3)
Re: (Score:2)
Re:Bad RNG will make your crypto predictable (Score:5, Informative)
Re: (Score:1)
yes, then drink the potassium chloride, and have someone time how long it takes you to die. that time will be sufficiently random for our purposes.
Re: (Score:1)
No, it will be sooner and less random.
Re: (Score:3)
The problem with FM static is that you could start receiving a station, and if you don't happen to realize you are now getting low-entropy data, that's a problem.
There are many well-characterized forms of electronic noise: thermal noise, shot noise, avalanche noise, flicker noise, all of these are easy to produce with parts that cost a few dollars.
Re: (Score:2)
The trouble with FM static is that your ''enemy'' could also observe what you observe and thus have a good idea of what you are basing your random numbers on.
Re: Bad RNG will make your crypto predictable (Score:2)
Wouldn't they also have to know your sampling frequency for that to be of any use? And I'm guessing if you randomized that, they'd have to follow your entire tool chain to get the same random result. I'm just thinking out loud here...
Re: (Score:2)
It also means that you're allowing an outside source, which is extremely easy to manipulate (a van parked outside your house with a transmitter) to create your random.
Thanks for the link (Score:1)
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!
Re: (Score:2)
Great resource! Thanks for this link.
Re:Bad RNG will make your crypto predictable (Score:5, Informative)
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.
Ehhhh, not always [2uo.de].
Re: (Score:2)
What I liked was the original version of PGP when it would ask you to type some random numbers/letters and would use that as a seed.
It depends on the crypto I was doing: For a number of tasks, say if I were rolling dice for a game, /dev/urandom is good enough. For generating a nonpersistant key (like a session key that is used and tossed during a SSL transaction), /dev/random. For a key that is persistant, it might be even better to use /dev/random, but also ask the user to toss in some random keypresses
Re:Bad RNG will make your crypto predictable (Score:4, Informative)
Most algorithms to do this use the time between keypresses, measured to very high precision so that the lower bits are chaotic. So it doesn't really matter what keys you hit, and it doesn't matter how rythmic your typing is.
Re: (Score:2)
If we pull numbers off a high precision clock function like Linux's clock_gettime (which has a nanosecond precision rate), it matters less what exact key the user pressed, because the part that rapidly changes (interval between keys, or even the absolute time (year/month/day/hour/minute/second/billionths of a second) can be used by running the output through a hashing algorithm and tossed into the RNG pool.
One you get into microsecond and nanosecond resolution, that is a quite usable random number source, s
Re: (Score:2)
Sweeping statement - not necessarily. Pre-shared keys and all that. It is possible to make good crypto systems without using random. Sorry to be autistic about it.
Re: Bad RNG will make your crypto predictable (Score:1)
I would think non random pre shared keys are attackable.
At the extreme case, you end up with a Caesar shift.
Re: (Score:2)
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.
Screw NIST (Score:2)
They're more like guidelines anyway.
Randomness can't come from a computer program (Score:3, 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.
Re: (Score:2)
Yes, but those have to use public-key encryption. I am sure of my one-time-pad encryption because it's just exclusive-OR with the data, and I am sure that my diode noise is really random and there is no way for anyone else to predict or duplicate it. I can not extend the same degree of surety to public-key encryption. The software is complex, the math is hard to understand, and it all depends on the assumption tha
Re: (Score:2, Interesting)
OneRNG - An Open and Verifiable hardware random number generator [youtube.com] -- 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 read
Re: (Score:2)
To throw another one out there - lower bitrate, different approach, much cheaper (especially if built yourself - designs are completely open): https://github.com/waywardgeek... [github.com]
Re: (Score:2)
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 randomizati
Re: (Score:2)
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.
Re: (Score:2)
Your reading comprehension needs some work.
A lot of effort to make sure bits aren't leaked (Score:3)
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?
Why should we trust NIST encryption? (Score:5, Insightful)
Re: (Score:2)
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.
Well you could go with the ANSI or ISO RNG specs.
Oh wait, they're written by the same people.
Re: (Score:2)
So the work begins again (Score:3)
To find out where the NSA put the twist.
Re: (Score:2)
To find out where the NSA put the twist.
Well P-224 isn't twist secure, if that's what you're hinting at.
In reality the backdoor isn't in SP800-90A, B or C. It's in FIPS 140-2 section 4.9.2. In a FIPS certified module, that procedure applies to all RNG outputs 16 bits and above. A test that changes the data to create a stream of known algebraic inequalities. Genius.
All these replies and no XKCD? (Score:1)
Yarrow isn't a thing? (Score:2)
The Yarrow algorithm, or its progeny Fortuna, are not yet a thing?
Shame.
https://en.wikipedia.org/wiki/... [wikipedia.org]