OpenBSD has taken it upon themselves to fix (or break, depending on your perspective) incorrect random number generation. Now Ted "tedu" Unangst has provided some examples of how not to generate random numbers. You won't believe the shit some programmers do!
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @01:15AM
yeah.
I can believe it.
(Score: 3, Funny) by meisterister on Thursday December 11 2014, @01:42AM
http://xkcd.com/221/ [xkcd.com]
I'm surprised someone hasn't written a script to do this automatically yet. I suppose that there's also a relevant Dilbert strip...
(May or may not have been) Posted from my K6-2, Athlon XP, or Pentium I/II/III.
(Score: 2) by Marand on Thursday December 11 2014, @02:12AM
I suppose that there's also a relevant Dilbert strip...
There is. [dilbert.com]
(Score: 2) by tangomargarine on Thursday December 11 2014, @03:23PM
Wasn't that pretty much how they cracked the PS3? There was a salt or something that basically was always 4, which made it a lot easier.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0, Informative) by Anonymous Coward on Thursday December 11 2014, @01:59AM
Who cares? OpenBSD is just a bunch of masturbating monkeys. Linus said so.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @04:12AM
While funny and snarky it is sort of true.
Not everything needs truly random and just needs something that is 'random' enough. Not everything needs encryption level random. If I were writing some sort of encryption routines I would not touch the stdio rand functions. http://linux.die.net/man/3/rand [die.net] in the man pages they describe what is going on. In pretty much every CS class I ever took they pontificated for a decent amount of time what it is.
This seems like a tempest in a teapot. I do however agree. At this point rand should no be that formula anymore. It should call out to hardware where it can and really be random.
(Score: 5, Informative) by maxwell demon on Thursday December 11 2014, @08:21AM
Indeed, sometimes true randomness is actually detrimental. If you use the random numbers for things like Monte Carlo calculations, reproducibility is a must. So you want a well-defined non-random seed (preferably settable as parameter, so you can cross-check your algorithm with a different sequence of "random" numbers).
On the other hand, if you are doing cryptography, you certainly don't want to use rand anyway, you want at least a cryptographically secure random number generator (with a truly random seed, of course).
So what remains? Games. But for games where real money is at stake, you'd certainly want true randomness, not a PRNG.
So what remains is games that are not played for money. For such games, all what counts is that it appears random. srand(time(0)) is typically sufficient for that.
tl;dr: If something along the lines of srand(time(0)) is not good enough for your purposes, then using rand for your random numbers is an error to begin with.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by mcgrew on Thursday December 11 2014, @01:53PM
Not everything needs truly random and just needs something that is 'random' enough. Not everything needs encryption level random.
Most insightful comment I've seen this thread! the only use for a truly random number that I know of is security, but security is only one use for a random number generator. All single player games use random numbers; I wrote quite a few of them in the '80s. No need for true randomness in a game, pseudo-random is good enough.
I think Microsoft and Gnome use random number generators to design their interfaces. "How can we make this control harder to find?"
mcgrewbooks.com mcgrew.info nooze.org
(Score: 2) by novak on Friday December 12 2014, @07:40AM
I've used various engineering softwares from the 80s, and one in particular (essentially a monte-carlo simulation) has a hard-coded "random" seed. This is especially interesting because when the software was originally written, the computer it ran on was not capable of running enough particles in the simulation to get a good statistically average result, and it was hard-coded to prevent it from running more particles. So now when it is run, there can be large differences between one run, and another essentially identical run. It doesn't help that the PRNG used is the infamous "RANDU" routine (http://en.wikipedia.org/wiki/RANDU).
This program is used to flight certify gas turbine engines for a major manufacturer, and that's why I'm scared of flying.
novak
(Score: 2) by cafebabe on Friday December 12 2014, @10:46PM
That's truly awful. The only benefit appears to be the speed of calculating an odd number as 32 bit integer and then casting it to a single precision float (which then culls the lower bits and makes it uniform between zero and a small fraction short of one).
1702845791×2
(Score: 2) by GungnirSniper on Thursday December 11 2014, @02:30AM
Is How Not to be Random the first step in turning teenage females into adults?
Tips for better submissions to help our site grow. [soylentnews.org]
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @02:50AM
No. It's to teach fanny bandits not incorrectly randomly choose another fanny bandit who has AIDS.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @03:33AM
From: Theo de Raadt
They are not random, not in any sense. All three subsystems produce deterministic results.
Gee, Theo, thanks for the amazing insight. I discovered something just the other day, that was equally earthshaking. Did you know that so-called "functions" written in C can actually have side-effects that change global state!? They shouldn't even be called "functions" at all! Maybe you can take up that campaign next.
(Score: 2) by tibman on Thursday December 11 2014, @05:31AM
He made srand non-deterministic (breaking ansi standard) and created a new method called srand_deterministic so that you can still access the old functionality. That is sort of the lazy approach. It seems like complying with the standard but creating a new srand_nondeterministic would be better. But then someone would have to go and replace thousands of srand usages. Tough call.
Deterministic random is still very useful. Especially in games but that doesn't really apply here.
SN won't survive on lurkers alone. Write comments.
(Score: 2) by bradley13 on Thursday December 11 2014, @09:10AM
Yes. He completely changed the functionality of a standard function, used by zillions of applications. This is really drastic stuff, to be undertaken only in the case of some sort of utterly critical problem. Was there one? No. He did this because he, personally, considers deterministic number sequences to be non-random simply because they are deterministic.
This is egoistic as hell. He's putting his personal peccadillo ahead of backwards compatibility with some unknown-but-large number of applications.
There is nothing at all wrong with deterministic random number generators, as long as the person using them knows that they are deterministic. Anyone using a random number generator for anything important will ask precisely that question (if they don't, then you have bigger problems). If they need something different, there are plenty of other generators available.
Everyone is somebody else's weirdo.
(Score: 2) by moondrake on Thursday December 11 2014, @01:57PM
I do not think it is egoistic. I think the problem the BSD-guys see here is that rand() functions are abused. Many people think they get a random number especially when they do silly things with the seed, whereas in fact, they get a pseudorandom number. For a game this might be OK, but for a secure application, its a disaster. OpenSSL really does this kind of shit, and that is very worrying...
To err on the side of caution they said, OK, we just give everyone who would like a random number a real random number. Since the relevant standards say very little about the deterministic nature of the pseudo-random numbers, you cannot (should not have) rely on them anyway. If you are fine with a pseudo-random numbers, and want clearly defined behavior for them, we provide new additional functions you can call instead.
Its a drastic approach, but I think it is induced not by egoism, but by a (perhaps OCD-like) desire to get rid of horrible misuse of rand() to generate somehow a real random number (by giving it time() or uninitialized variables as seed).
(Score: 2) by tangomargarine on Thursday December 11 2014, @03:29PM
Maybe it was with good intentions, but I can't say forcing programmers to "be better" by changing their standard API without telling them and potentially breaking the software of those who DO know what they're doing is a good way to go about it.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @03:31PM
And for a scientific application, a truly random rand() is a disaster (as is for debugging, BTW). Bye bye, reproducibility.
(Score: 2) by Bot on Thursday December 11 2014, @04:33PM
Ok but how many of those zillion applications actually want a deterministic rand() and break otherwise? Especially given the reason people run things under openbsd.
Account abandoned.
(Score: 4, Interesting) by frojack on Thursday December 11 2014, @04:08AM
We read all the books. Followed all the examples, and still weren't all that trusting.
For seeds, we tend to use some varying hash of date and time and something from the machine itself (often uptime) as a seed.
We also tend to use keys or short periods of time before re-negotiating keys (this is for encrypted internet connections).
One side (or the other) decides when its time to renegotiate. Again on a random-ish basis.
We don't even pretend this is three-letter-agency secure, its just very hard to reproduce because someone has to know a lot of things, and get them just exactly right because on bit off, and you are toast.
So even with access to the source code its hard to get these things right, and then have to re-do it again some shortish random-ish time later on command of one side or the other.
We aren't mathematicians. We've always distrusted them and their fancy-ass random number generators. Still we have to use them, so we try to use them randomly. We aren't in a position to outsmart those guys, so we make them work harder.
No, you are mistaken. I've always had this sig.
(Score: 2) by ilPapa on Thursday December 11 2014, @04:25AM
I like the cut of your jib.
You are still welcome on my lawn.
(Score: 2) by HiThere on Thursday December 11 2014, @09:11PM
O...K. But different purposes have different needs WRT random numbers. When stage 1 testing I always use the date the code was written (in some form or other). But my random number needs aren't about security, they're about getting a random distribution. I could use a hash of the name of the program. Anything that's basically unpredictable and intentionally repeatable. And you can't generate actual random numbers from a computer unless you have hardware errors. Even disk seeks and key presses are less than actually random. I suppose that one could come up with something sufficiently random for most purposes by taking the number of microseconds between key strokes modulo some small number and accumulate them, but then you run out of randomness. If you want real random numbers, use a geiger counter, or some similar approach. (I believe good results have been gotten with a photocell and a fire. Lava lamps seem to work, but are too slow to be useful. Perhaps something could be made out of the time between internet signals?)
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by timbim on Thursday December 11 2014, @05:04AM
Any one who considers arithmetical methods of producing random digits is, of course, in a state of sin. For, as has been pointed out several times, there is no such thing as a random number — there are only methods to produce random numbers, and a strict arithmetic procedure of course is not such a method.
(Score: 2) by threedigits on Thursday December 11 2014, @07:54AM
there is no such thing as a random number — there are only methods to produce random numbers
This needs clarification. There are methods to pick numbers randomly (meaning, that the next outcome appears cannot be predicted by knowing the previous ones).
It makes not much sense to say that there are no random numbers, and on the next sentence claim there are methods to produce them.
(Score: 1) by mr_mischief on Thursday December 11 2014, @04:31PM
There are ways to pick numbers, especially those using input from hardware that takes readings from the world outside the computer, that are difficult or impossible to predict. This is actually the important part. Whether those numbers (from radio noise, light noise, radioactive decay, small heat fluctuations in a chip, etc) are really truly random is harder to state. Making sure someone can't predict the next number based on the code state is the important part.
(Score: 2) by HiThere on Thursday December 11 2014, @09:19PM
Even that is overstating the case. For some purposes it's important that the next number in the series not be predictable. For other purposes it's merely necessary that it be independent of the algorithm that's using it. If you're storing data into an array "randomly" you just want to minimize collisions, and make it so that the program using the array can't predict the order in which the data will be placed. Some pretty simple "random number generators" will usually work for that purpose. If, e.g., you're programming a game and you want to randomly select the next action of some NPC, you don't need a high quality random number generator. and it's not worth the work. Any normal pseudo-random generator will suffice, though you might want to specify a flat rather than a normal distribution. Etc.
For other purposes, it's worth while to use a camera looking at a fire to generate random numbers.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by black6host on Friday December 12 2014, @02:31PM
Please pardon my ignorance (I'm trying to correct it :) ) What method do you use to obtain a number from an image (or video) of a fire?
(Score: 2) by HiThere on Friday December 12 2014, @08:12PM
There are lots of different methods, but they all boil down to you resolve the image into a stream of numbers that you sample. You probably want to calculate a mean value for any particular element that you are are sampling and use the difference from the mean as your random value. You could handle the video as a series of stills and sample variation in any particular part of the image. Or other approaches. Exactly what technique you use would depend on what your purpose was. (Do you need a Normal distribution? A flat distribution? Etc. You probably should prefer modular values over threshold values. Etc.)
P.S.: I'm no expert in this area, and have only a very nodding acquaintance with the idea, but that's the basic approach.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 0) by Anonymous Coward on Sunday December 14 2014, @10:15PM
Thank you. Now I'm not quite as ignorant :)
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @07:00AM
Some of these examples are only dangerous in a security context. The summary should state that.
(Score: 3, Insightful) by No.Limit on Thursday December 11 2014, @08:23AM
Depending on your requirements you will want to have random number generators with different properties:
There are good reasons to have different kinds of random number generators. But most importantly programmers should know what their requirements are and then choose one appropriately.
(Score: 2) by TheRaven on Thursday December 11 2014, @06:25PM
sudo mod me up
(Score: 4, Informative) by bradley13 on Thursday December 11 2014, @08:56AM
Most of the code snippets the guy makes fun of are choosing seeds to start random number generation. A few of them go to crazy lengths without actually adding anything useful, but most are doing something pretty simple. And why not? Most applications of random numbers are not trying to keep out the NSA.
Just as an example: The last time I used a random number generator in a business application, it was for cache management - I didn't want a zillion caches doing a DDOS on the database server, so each cache adds a small random factor to its refresh period. I'm sure I used something really simple, and why not?
Nearly all of the code snippets - after choosing the seed - just go on to use a standard random number generator, which is exactly what they ought to do.
- If you have an application where you just want a uniform distribution of numbers with no obvious pattern: seeding with 0, 1, your birth year, or your dog's age - any constant is just fine. Depending on the the random number generator (whether or not it's deterministic), this may give you repeatability, which some applications actually want.
- If you want to be pretty sure that each run of the program will use a different sequence of numbers, using a time-based function is a logical solution. If there's some chance that two processes might be started in the same second, then you may well want to use milli-, micro- or nanoseconds.
Since he gives no context for any of the snippets, I am going to go out on a limb and say: Most of them are perfectly fine. Probably very few of them are trying to produce secure cryptography. He's acting all superior and picking on code that is probably just fine for it's intended purpose. Color me unimpressed.
Everyone is somebody else's weirdo.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @03:43PM
And why not?
Because it's not really doing anything useful. A proper seed should come good entropy sources that the OS controls not from the developer thinking he can gather entropy in better ways.
(Score: 0) by Anonymous Coward on Thursday December 11 2014, @03:54PM
Moreover, I'd say if someone uses rand() for cryptography, the solution is not to change rand but to use different software, written by someone who has a clue what he does. After all, it is very likely that anyone who thinks rand() is an appropriate function to use for cryptography will also hold some other, equally dangerous believes which also manifests themselves in security problems of the code.
Even worse, someone who only programs on OpenBSD with a replaced rand() is more likely to get the delusion that using it is OK for cryptography, causing more software to become insecure as soon as it gets used on standard conforming systems. So this decision decreases general security.
Well, I just hope the OpenBSD developers get drowned in bug reports from people who depend on the correct behaviour of rand() (or maybe, OpenBSD will become the reputation of an operating system to avoid due to its malfunctioning rand()?)
(Score: 2) by bob_super on Thursday December 11 2014, @04:54PM
Or someone is getting a piece of code abusing rand(), and is not allowed to touch it because someone else certified it for Cryptography, and it would take 12 months to re-certify it, after spending 12 months convincing people there needs to be a change.
So they try funky stuff with seeds ...
Either that, or the generation of random numbers happens to be a place where the coders can have some fun pretty harmlessly (if not crypto)...
(Score: 0) by Anonymous Coward on Friday December 12 2014, @12:07AM
Sheesh
Someone trIes to write a good random number generator and 99% of the posters on here shoot him down. Because a deterministic, algorithmic PRNG is better. Because reasons.
Limited entropy is good! We've always been at war with eastasia!
(Score: 2) by maxwell demon on Friday December 12 2014, @07:12AM
There's nothing wrong with writing a good random number generator. There is a lot wrong with changing the behaviour of a function that does not, and is not meant to, produce true random numbers, to use it, making it not standard conforming and breaking every single code that relies on the standardized behaviour.
The Tao of math: The numbers you can count are not the real numbers.