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

121–130 of 214 posts

Re: Should random() be banned?

#121

Post by ChrisLomont »

mmazing wrote: post #110
extropy wrote: post #96

Earlier quoted context omitted.

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

>the impact of not using true random could cause a catastrophic result for a large number of people.

And the impact of using 1000x slower trueRandom could cause catastrophic results for an even larger number of people, since by far PRNGs are used where speed is more important than security.

And once you pick a "true random", how true is it? Will it be secure in 10 years? Will we then need a "truerTrueRandom" to mitigate that true random has failed to pass future mathematical or hardware tests? Will it return random numbers fast enough for future uses?

It's a rabbit hole. Let developers use the one they need, and since the vast majority does not need secure random, don't force it on them at significant cost.

If your crypto developer cannot know which to use you're going to have a lot more holes in your crypto than the RNG.

Re: Should random() be banned?

#122

Post by ChrisLomont »

MauranKilom wrote: post #117
patrec wrote: post #94

Earlier quoted context omitted.

Mersenne Twister is the MD5 of random number generators: it's neither secure nor fast (and unlikely md5 not space-efficient, or simple to implement either). You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the…

> You can have something that has better randomness, runs several times faster, uses less space and has a much more compact and simple implementation. Could you share at least one example of such a generator? Most of these aspects are trivial to improve on, but having "better randomness" on top is quite the bar.

The PCG class of PRNGs are very good, and have a zillion tunable versions to suit every need.

https://www.pcg-random.org/index.html

Re: Should random() be banned?

#123

Post by ChrisLomont »

tedunangst wrote: post #48
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.

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

If you're using it to give hands to people, then no. If you suitably hash or whiten the outcome, then yes.

If you're using it to generate Monte Carlo hand playouts to generate % outcomes to assist such a game, then you most certainly want an extremely fast generator. Only slightly more complex than a LCG is the PCG class (based on a PCG, and it's just as simple and fast in most cases as a LCG). And you'll need such Monte Carlo simulations to detect cheating, among other things.

So even for an online poker game you need to know what you're doing. Neither type of RNG will solve all the issues you need.

So yes, at the base a simple LCG would suffice if you know how to use it.

https://www.pcg-random.org/index.html

Re: Should random() be banned?

#125

Post by nemo1618 »

moonchild wrote: post #113
nemo1618 wrote: post #86

The root problem here is the notion that you need to choose between "strong and slow" randomness vs. "weak and fast" randomness. If every language's random() was strong and fast, most developers would never have to think about it. "Strong" randomness is often too slow because every time you ask for new entropy, you make a syscall. The solution is to use 32 bytes of strong randomness to seed a userspace CSPRNG. You ca…

> The solution is to use 32 bytes of strong randomness to seed a userspace CSPRNG All cryptographic randomness generation should be performed by the kernel. You always have to think about security because if you don't think about security you're going to get hacked . By all means, name the insecure randomness generation function ‘insecure_random’. It does help. But secure-by-default helps you only marginally because…

That's fair. There's no silver bullet for security. But we should not let the perfect be the enemy of the good. Everyone writing non-trivial systems should have some understanding of security; but the more components we make secure-by-default, the less those developers need to learn.

Re: Should random() be banned?

#126

Post by [deleted] »

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.

[deleted]

Re: Should random() be banned?

#127

Post by MauranKilom »

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.

> No mention of arc4random(3)? Seems like a solved problem in BSD land.

Do you mean the "real" arc4random algorithm, or ChaCha20 (which is what arc4random actually is on OpenBSD)?

See also:

> OpenBSD was sufficiently dissatisfied with it that they replaced it with a generator based on the ChaCha20 stream cipher.

https://www.pcg-random.org/other-rngs.html

Re: Should random() be banned?

#128

Post by ddtaylor »

sobriquet9 wrote: post #28

The problem is not random() itself, it's constructs like random() % n. Even if you replace random() with a CSPRNG, misuse won't go away.

I don't agree. I think Python and a few others do a good job by making random range based functions like `randrange` at curbing misuse.

Re: Should random() be banned?

#129

Post by asveikau »

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…

This was specifically a discussion of the impact of purposefully breaking a strict interpretation of a POSIX API, though. They looked at where it was used, which is appropriate.

Re: Should random() be banned?

#130

Post by adrr »

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?

I’ve seen guids used as secrets on APIs/cookies. Those are easily guessable and also not random.
Post reply on HN