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

101–110 of 214 posts

Re: Should random() be banned?

#101

Post by kevin_thibedeau »

admax88q wrote: post #76
throw0101a wrote: post #68

Earlier quoted context omitted.

Some folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mea…

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?

Re: Should random() be banned?

#102

Post by stefan_ »

hannob wrote: post #30
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.

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…

Obligatory mention here for the fine folks of systemd, who have made a properly seeded CSPRNG a requirement for merely booting a system and then kept bricking peoples systems when it turns out finding that seed at boot time is a non-trivial problem. All for what, avoiding collisions in some hash table implementation?

I don't really care for the browser application, if you made a TLS connection in the first place obviously you better have the randomness and might as well make random() use that, but someone explicitly using a CSPRNG in a native application is a huge code smell on the level of implementing your own crypto.

Re: Should random() be banned?

#103

Post by creata »

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.)

Say you're making an online game, and you need an RNG on your server. Above all, this RNG needs to be unpredictable, or someone will easily game it. Most non-cryptographic PRNGs are very predictable, so it's dangerous to use them.

I think this is a scenario that (a) isn't "extremely niche," and (b) warrants CSPRNGs.

Re: Should random() be banned?

#104

Post by [deleted] »

1MoreThing wrote: post #71
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 -…

The creation of a trueRandom function certainly seems to solve this problem more than taking away a useful tool for cases where pseudo-random is good enough.

[deleted]

Re: Should random() be banned?

#105

Post by iainmerrick »

wilsonthewhale wrote: post #81

No mention of arc4random(3)? Seems like a solved problem in BSD land. The key takeaways I feel like are: 1. You want as simple of an interface as possible. arc4random(3) returns a single random 32 bit integer, or you can tell it to fill a buffer with them. 2. Just make it cryptographically secure. arc4random does it and it seems to be fine.

The only problem is the weird name. It should just be random().

If there’s a not-so-good-but-faster version, call it fastRandom() or cheapRandom() or randomish() or something like that.

Re: Should random() be banned?

#106

Post by h_anna_h »

admax88q wrote: post #76
throw0101a wrote: post #68

Earlier quoted context omitted.

Some folks purposely want random-ish results. When OpenBSD was changing the behaviour of its legacy POSIX random functions it was observed: This API is used in two patterns: 1. Under the assumption it provides good random numbers. This is the primary usage case by most developers. This is their expectation. 2. A 'seed' can be re-provided at a later time, allowing replay of a previous "random sequence", oh wait, I mea…

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…

> If you want predictable "random" numbers, you should have to jump through additional hoops

Why?

> By default random numbers should be cryptographically secure.

Why not both?

Re: Should random() be banned?

#107

Post by iainmerrick »

zinkem wrote: post #32

I most commonly use random() for generating names (e.g. docker's container names) and generating test inputs. I don't care about cryptographic safety in either case.

I wouldn’t imagine you care that much about speed either, right? Unless you’re generating gigabytes of random test data, maybe.

Re: Should random() be banned?

#108

Post by JauntyHatAngle »

FalconSensei wrote: post #73
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 -…

Also: if someone is working on crypto and doesn't know that random() isn't true random, should they be working on that?

The level of expertise far outstrips the demand in my experience, so the "should" often becomes moot.

Re: Should random() be banned?

#109

Post by mmazing »

Macha wrote: post #61
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…

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 -…

That's all great and makes sense, but ...

What does that have to do with being verbose and letting developers know they are using an insecure method when it would apply to them?

If I'm writing code and using rng for gameplay variety, and then I notice that I have to use a function called "insecureRandom", at the very least I'm going to read up on an interesting aspect of computing and be a little more informed at the end of the day.

Re: Should random() be banned?

#110

Post by mmazing »

extropy wrote: post #96
1MoreThing wrote: post #71

Earlier quoted context omitted.

The creation of a trueRandom function certainly seems to solve this problem more than taking away a useful tool for cases where pseudo-random is good enough.

The problem is that true random is quite expensive without dedicated hardware and you can still easily bias true random if you are not careful. IMO there is no use of true random unless you really know what you are doing. Also there is true random - pure entropy bits and there is cryptographically secure pseudorandom, seeded with true random bits.

It's really not clear cut in either way on the surface.

On one side, you can argue that leaning people towards true random will cause unnecessary performance impact because the majority of cases don't need true random.

On another side, the impact of not using true random could cause a catastrophic result for a large number of people.

So which has more weight? I dunno.

In either case, it would be nice if developers knew the consequences of using either method, so this discussion is really more about education than anything else.

Post reply on HN