Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Should random() be banned?

r2c.dev

Post reply on HN
Print view View original

171–180 of 214 posts

Re: Should random() be banned?

#171

Post by watwut »

bigiain wrote: post #152
SomeCallMeTim wrote: post #66

Earlier quoted context omitted.

Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to hav…

Patterned random numbers become a feature in some games, even if an unintentional one. I used to be able to play about a dozen Pac-Man levels knowing exactly where every ghost was going to go and every bonus that was going to appear. And I wasn’t a very good player. Pac-Man would have been a less fun game for many people if it used crypto grade random.

Pac-Man ghosts did not moved all that much randomly. Each ghost had special follow up strategy. You likely learned their movement patterns without realizing it.

Re: Should random() be banned?

#172

Post by Dylan16807 »

Khaine wrote: post #167
Dylan16807 wrote: post #140

Earlier quoted context omitted.

You don't modify shuffle to make it seem more random, you modify shuffle because a non-clumping algorithm is more pleasant.

It's more pleasant because it is less random. I naive implementation might use true randomness which to a human doesn't appear random. https://www.businessinsider.com.au/spotify-made-shuffle-feat...

Right, I'm not disagreeing with that.

But I bet that the main goal is not "Let's make this change so it sounds more random, and then people will like it because they think it's randomer." Rather, it's "Let's make this change so it sounds better, and also as a side effect people might think it's more random."

Re: Should random() be banned?

#173

Post by IcePic »

kevin_thibedeau wrote: post #101
admax88q wrote: post #76

Earlier quoted context omitted.

This is exactly what I mean about being stuck in the C mindset. You're looking at the problem though the lens of what this giant pile of ancient C software does. Why should newer languages take the same approach to APIs that these old code bases did? It's not like we're porting all those programs to JS. Those C APIs were written long before hardware could provide fast good randomness, heck even before cryptography wa…

A reproducible pseudorandom sequence is necessary for fuzz testing with randomized inputs. It isn't strictly the domain of "ancient C". Why should everyone be hobbled by security guarantees they won't need?

Do you have a guarantee that random() will give you the same sequence on different endians, on different libcs, on different 32/64bit arches, on different OSes or even dists?

The expectation of reproducability is probably lost if you switch any of the above "details", so the problem with bad-random-generation is that it's not only the people who thinks the entropy is good in it that are wrong, the ones that think rand() didn't change in the last 40(?) years are equally wrong.

Re: Should random() be banned?

#174

Post by IcePic »

Quillbert182 wrote: post #85

Semi-unrelated question: How secure are the hardware random number generators on say, a raspberry pi. Would these sort of things be cryptographically secure?

I think those built-in RNGs should be treated like RDRAND on x86, you may mix them into the pool along with all the other sources of entropy your platform supplies, and then generate cryptographic streams seeded out of the pool. Using them alone might turn out to be a bad idea in the long run.

Re: Should random() be banned?

#175

Post by [deleted] »

SomeCallMeTim wrote: post #66
njharman wrote: post #39

Earlier quoted context omitted.

Most simulations, games, everything that isn't generating cryptography does not need security in it's random. For most domains secure random is a niche, not universally applicable.

Actually, in my experience using the default random implementation in games: * It's not fast enough. * It has patterns that can be seen if you are using it to, for instance, generate 2d noise. So for games you'd typically use, say, the Mersenne Twister [1], which is faster (amortized) and is distributed evenly across 623 dimensions. [2] It's not cryptographic, but it's far better for games. If you're not going to hav…

[deleted]

Re: Should random() be banned?

#176

Post by tiborsaas »

makeworld wrote: post #124
tiborsaas wrote: post #20

Meanwhile in graphics programming land: float rand(vec2 co){ return fract(sin(dot(co.xy,vec2(12.9898,78.233))) * 43758.5453); }

Could someone explain this? How is it used, why does it take a vector as input, where do the magic numbers come from, etc.

It's written in GLSL which is a C like language for shaders designed to be executed on the GPU.

The 2D vector used for input is to represent pixel coordinates mapped from 0 to 1 or -1 to 1 on both axes.

The magic numbers are nothing special, they are just large numbers to make the result unpredictable for the given input.

The top level function is a fract which takes the fractional part of a number. So if the result of the inner computation is twisted enough it will be hard to trace it back to the original values. There are lots of variations for these one liners, most of the do a great job to produce noise.

Re: Should random() be banned?

#177

Post by hombre_fatal »

matthewdgreen wrote: post #135
hombre_fatal wrote: post #132

Earlier quoted context omitted.

Not sure what you have in mind when you say guids, but the word guid doesn't confer any info here. Most people are referring to uuids when they say guid, and a v4 uuid has 122 bits of randomness. A random 122 bit number can certainly be sufficient for most applications like api keys over the network.

Some standard uuid libraries have weird not-very-random fallbacks when the RNG fails to initialize. It’s rare, but you can get strange stuff without realizing it. Better to use a real RNG and check error codes.

Yep, there's no rule of thumb that can spare you from reading the docs and knowing basic things about the code you're about to pull in.

Re: Should random() be banned?

#178

Post by hyperman1 »

andoriyu wrote: post #95
nicoburns wrote: post #41

Earlier quoted context omitted.

React's dangerouslySetInnerHTML is indeed a good way of handling this kind of thing. Rust's `unsafe` is another example of the same approach.

uhm no. Rust's "unsafe" is a pretty bad name and completely different reasoning behind using it. It doesn't mark something as "dangerously unsafe, don't use", to a consumer it indicates "exercise caution" and to a compiler it just allows 5 things: Dereference a raw pointer Call an unsafe function or method Access or modify a mutable static variable Implement an unsafe trait Access fields of unions The point of "unsaf…

Isn't this just part of the world view of Rust?

The word 'safe' in Rust has a very specific, technical meaning. 'unsafe' is simply code that is not automatically 'safe' in the Rust sense.

A non-Rust developer sees safe/unsafe and gets worked up, but that just means that he should put his rust-colored glasses [*] on.

This is not unusual in ICT, known for its colorful language. A non-ICTer hears 'black hat' and thinks about how cool and stylish the hat is. An ICTer hears 'hacker' and thinks about how cool and stylish the hack is.

[*] Thanks, Raymond!

Re: Should random() be banned?

#179

Post by hyperman1 »

makeworld wrote: post #124
tiborsaas wrote: post #20

Meanwhile in graphics programming land: float rand(vec2 co){ return fract(sin(dot(co.xy,vec2(12.9898,78.233))) * 43758.5453); }

Could someone explain this? How is it used, why does it take a vector as input, where do the magic numbers come from, etc.

random typically works by storing/modifying some state, so every call with the same argument results in different numbers.

In shaders, the same code is executed in parallel for potentially every pixel. Storing state would mean pixels could only be calculated serially, slowing things down.

Hence you need a random-ish function that depends only on its input. Very low RNG quality is not a blocker, as long as things look good.

So in shaders you see a lot of random generators which simply take the pixel coordinate or something else that distinguishes 2 pixels and do some nonsense operations on them.

Re: Should random() be banned?

#180

Post by Macha »

ThePadawan wrote: post #169
Macha wrote: post #61

Earlier quoted context omitted.

This assumes writing crypto code is the most common use case for random numbers. How often do you write crypto code? vs How often do people use random numbers + threshold for A/B tests? How often do game developers use random numbers for gameplay variety? How often is random used for animation variety? Do these use cases need the overhead of a cryptography RNG? A former employer had the same issue as in the article -…

Did you mean to reply to my comment? I don't disagree with anything you say, but it also doesn't refer to my comment.

Why not? I feel the same about naming a method to shame/discourage use as you suggested for outright banning. It shouldn't require a justification to use non-CSPRNG, because most use cases I run into for random are not crypto, because I don't write my own crypto.
Post reply on HN