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

131–140 of 214 posts

Re: Should random() be banned?

#131

Post by repsilat »

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…

> You can generate gigabytes of secure entropy per second in userspace.

I haven't thought about this before, so please have patience:

I guess the "secure" qualifier does a lot of work in this sentence? That there's 32 bytes of "true entropy", but "secure entropy" is theoretically weaker but practically just as strong with reasonable assumptions about an attacker's computing resources.

So I'd guess the "secure" qualifier must mean something like "given any quantity of derived pseudorandom information, the seed bytes can't be efficiently deduced? Pretty neat. (I had a knee-jerk disagreement until I re-read your post and saw that you said "32 bytes", not "32 bits". Quite plausible -- and cool -- that we have a good solution with just a small amount more seed randomness though.)

Re: Should random() be banned?

#132

Post by hombre_fatal »

adrr wrote: post #130
FalconSensei wrote: post #73

Earlier quoted context omitted.

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.

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.

Re: Should random() be banned?

#133

Post by tgsovlerkhgsel »

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

I genuinely don't see the reason why non-cryptographic random number generators exist outside of niche applications.

The main arguments I've seen are speed and determinism.

However, a cryptographically secure, deterministic PRNG can be built from hash or block cipher primitives that have hardware acceleration, making them quite fast. Seed (and potentially periodically re-seed) it from a strong source of randomness, and you've got a fast and cryptographically secure non-deterministic PRNG.

I thought that "classic" PRNGs like the widespread Mersenne Twister even had issues that can cause practical problems when used in certain kinds of simulations (Monte Carlo, possibly) that rely on large amounts of random numbers, but I haven't been able to find a clear source for this.

I'm certainly defaulting to secure ones, and I'm surprised modern languages and libraries don't do this by default for their standard randomness functions.

Re: Should random() be banned?

#134

Post by repsilat »

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?

> fuzz testing

Also reproducible builds, non-fuzz testing of very complex systems, the list goes on.

Quite often CS papers describe randomized data structures and algorithms. Quite often (at least historically, not sure now) ML models were seeded from random states.

If you want something to be algorithmically reproducible, you need some pretty strong guarantees from component parts. If you're using a hash table, and that hash table makes use of nondeterministic state that you can't control, you need to make sure that you're not using it in a way that lets that nondetederminism leak out -- if it doesn't provide a deterministic iteration order, you shouldn't iterate over it.

Sometimes determinism can be won back (just using lookup methods on your hash table, sorting the hash elements after iterating over the hash table) but in some cases it's not really possible, and in many cases it's at least impractical. Not providing a mechanism for nondeterminism in the first place can be simpler, but it comes with different problems. (Security problems are an obvious example -- an OS that gives deterministic bits when you ask for random bits is a worry.)

Re: Should random() be banned?

#135

Post by matthewdgreen »

hombre_fatal wrote: post #132
adrr wrote: post #130

Earlier quoted context omitted.

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

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.

Re: Should random() be banned?

#136

Post by Khaine »

patrec wrote: post #94
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…

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…

Doesn't FreeBSD use Mersenne Twister as its CSRNG?

Re: Should random() be banned?

#137

Post by adrr »

hombre_fatal wrote: post #132
adrr wrote: post #130

Earlier quoted context omitted.

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

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.

Guids is uuid and they can be interchanged but they all have same concept of creating unique identifiers that won’t ever collide.

It isn’t random is the problem and they are are used everywhere as a secret. People think they are random 122bit value.

Re: Should random() be banned?

#138

Post by Khaine »

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

The other thing is, true randomness doesn't seem random to humans. Which is why spotify and others had to modify shuffle. So true random might not be appropriate for the use case.

What is appropriate to use comes down to context.

Re: Should random() be banned?

#139

Post by Dylan16807 »

adrr wrote: post #137
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.

Guids is uuid and they can be interchanged but they all have same concept of creating unique identifiers that won’t ever collide. It isn’t random is the problem and they are are used everywhere as a secret. People think they are random 122bit value.

No, that's why you need to be specific. v4 is random, other versions aren't.

Re: Should random() be banned?

#140

Post by Dylan16807 »

Khaine wrote: post #138
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 other thing is, true randomness doesn't seem random to humans. Which is why spotify and others had to modify shuffle. So true random might not be appropriate for the use case. What is appropriate to use comes down to context.

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