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

41–50 of 214 posts

Re: Should random() be banned?

#41

Post by nicoburns »

ThePadawan wrote: post #3

I'm not big on bans. What I am big on is forcing developers to make deliberate choices. That's why I like React's policy of naming functionality "dangerouslySetInnerHTML" or "__SECRET_DOM_DO_NOT_USE_OR_YOU_WILL_BE_FIRED". If you add usages for these in a PR I'm reviewing without justification, it's not getting merged. So why not make cryptographically unsafe random unsafeRandom() or shittyRandom() or iCopyPastedThisF…

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

Re: Should random() be banned?

#43

Post by epanchin »

njharman wrote: post #39
cogman10 wrote: post #26

Earlier quoted context omitted.

That's be my preference. random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.

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.

And one would hope secure devs know which random to use, whereas gaming devs have no reason to know.

Re: Should random() be banned?

#44

Post by pdpi »

bob1029 wrote: post #33

It's all about the discipline of the team in the end... You can ban things all day, but it just takes 2 developers deciding they don't give a shit to code, review & merge that use-fast-random-for-session-token PR. There is more than 1 way to get something that is "random", so basic string matching for methods you don't like is certainly not a guarantee. In our organization the policy is very simple. We have static me…

> Communication with your team is more important than writing check-in rules to prevent bad things from happening.

There's some subtlety here. This is sort of a security vs safety issue.

Some people are just reckless, and that's a human problem that is best dealt with through a stern talking to (or, ultimately, termination) rather than technical measures. You'd require an oppressive amount of check-in rules in place to be even remotely effective at stopping this behaviour, and those would just make life miserable for everybody else.

Some people are new to the team and/or just plain inexperienced, and it takes time for them to absorb all the standard practices so they can innocently cause trouble. Even veterans will make mistakes. Low friction guard rails can help keep those people from getting into too much trouble without being too onerous.

Re: Should random() be banned?

#45

Post by f430 »

Is it possible to have something like random.org but without paying for it?

say you want to build a lottery application, who can you rely on to make receive a very good random number generator at low cost?

Should the government provide this for free to developers? Seems like its in everybody's interest to have a ~true random() function.

Pokerstars uses lasers, someone else uses lava lamps, radio waves, what else?

Also on a side note: how much do you think we have truly discovered the nature of "randomness"? Nassim Taleb says its not random if you run into somebody you know in the supermarket while thinking of them. Some physicists have likened it similar to newtonian others a more parallelian view. Why is it that some natural order emerges out of "randomness" out of a 52 card deck? How is it that a randomly swinging spot light in a dark room is able to "find" a plant that is also "randomly" placed in the room? Or the randomness of people's birth date and time emerging in lottery tickets? Or even more controversial, the fact that RNG is able to be seemingly influenced by the collective consciousness?

Re: Should random() be banned?

#46

Post by pdpi »

gwbas1c wrote: post #36
hannob wrote: post #30

Earlier quoted context omitted.

The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes. Not true the other way round. And I'm inclined to say given how many misconceptions around randomness there are around, I don't think people are good at knowing whether they need secure randomness. The only possible justification for insecure randomness would be performance, but you'd need to generate a lot of rando…

> The cryptographic randomness has practically no downside if you use it for non-cryptogrpahic purposes Cryptographic randomness is typically slower than other forms of randomness. In all of the programming I've done in my career, I've only needed cryptographic randomness a few times. For the rest, a fast pseudorandom number generator seeded by the clock was the correct choice.

Inversely, in my career there's only been a handful of times where cryptographic randomness was too slow.

I'd argue it's better to do the safe thing by default and switching to the faster alternative when you have proof you need it. Doing the fast thing by default and fixing security later is how we got Meltdown/Spectre.

Re: Should random() be banned?

#47

Post by tedunangst »

otabdeveloper4 wrote: post #15
madsbuch wrote: post #4

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

What bad things will happen if I use cryptographic random for a non niche use case?

Re: Should random() be banned?

#48

Post by tedunangst »

njharman wrote: post #39
cogman10 wrote: post #26

Earlier quoted context omitted.

That's be my preference. random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.

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.

So a simple linear generator is fine for an online poker game?

Re: Should random() be banned?

#49

Post by madsbuch »

tedunangst wrote: post #47
otabdeveloper4 wrote: post #15

Earlier quoted context omitted.

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

What bad things will happen if I use cryptographic random for a non niche use case?

It is expensive to increase entropy of a random source. So for randomised algorithms you might not get the performance that merited the algorithms in the first place.

Re: Should random() be banned?

#50

Post by mreome »

otabdeveloper4 wrote: post #15
madsbuch wrote: post #4

Is there something I am overlooking here? Randomness is used for many other things than cryptographic usages. Eg. for randomised algorithms you need a fast source of randomness.

No, you are not. Cryptographic random() is an extremely niche use case that you shouldn't be using unless you're writing your own crypto libraries. (Don't do that.)

It's not that you shouldn't be using it necessarily, it's just that for many cases (games, procedural generation, graphics, many kind of simulations) it's unnecessary and slow. In my experience if someone doesn't know if they need a cryptographicly secure random(), or if a given random() implementation is secure then they (a) don't need it or (b) are trying to implement something they shouldn't be.
Post reply on HN