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

111–120 of 214 posts

Re: Should random() be banned?

#111

Post by antonyh »

dbcurtis wrote: post #88
antonyh wrote: post #80

Seeded random is a glorious thing in the right circumstances. As an example, I've used it for 'random' testing sequences (jumbling up a list of inputs) but in a way I can later re-run EXACTLY the same test. It's also useful for other data generation tasks where the output can basically be saved as a seed, making it lightweight and easy to store - it could be written it on a scrap of paper in seconds. Maybe it's a bad…

Came here to say this. I have spent a lot of time in hardware validation. Pseudo-random (explicitly NOT random) sequences are hugely useful. I once had a lights out server room of 60 servers whose entire purpose was to take skeletonized tests and a seed for a pseudo-random function and generate a test instance. That test instance went to one of a dozen test jigs. What was recorded was: pass/fail, the git sha of the t…

That sounds awesome, and the use of a repeatable random vital. Another example of random in a non-cryptography context where it's unpredictable under normal operation, but completely predictable when needed. If you wanted you could run the same test on all the test jigs with different seeds, safe in the knowledge that you could re-run all of them exactly again and again if required. Or you could add problematic seeds to a list for repeated retest with future versions. So much power and freedom!

Re: Should random() be banned?

#112

Post by creata »

mreome wrote: post #55
jcranmer wrote: post #54

Earlier quoted context omitted.

That's not true. To answer the question as to when you should use cryptographic random(), ask yourself "What is the worst that could happen if someone guesses the result of random()?" If the answer is "I don't know," go cryptrographic. You'll save your butt if you didn't know it was important. If the answer is along the lines of "someone could impersonate a user, or leak information they shouldn't see," for the love…

I would argue that if you're asking yourself "What is the worst that could happen if someone guesses the result of random()?" and your answer is "I don't know," then you're doing something you shouldn't be doing. There are a lot of domains where security is a non-issue and performance is a huge concern (graphics, game logic, many kind of simulations, etc), and the default is the reverse... always just use the install…

> then you're doing something you shouldn't be doing.

I agree! But I also think a standard library should withstand a bit of abuse from people who don't know what they're doing.

Re: Should random() be banned?

#113

Post by moonchild »

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 when building secure software you don't get to just use the defaults; you have to think about what they're doing.

You have to (for example) know and think about timing attacks even if you're using a cryptographic primitives library that's hardened against them, because it's really easy to introduce timing dependence into your own code and none of Daniel Bernstein or Tanja Lange’s careful designs will save you.

Re: Should random() be banned?

#114

Post by chromanoid »

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.

Pseudo random is sometimes even necessary. It's really cool when you generate reproducible test data via seeds.

Re: Should random() be banned?

#115

Post by aaomidi »

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?

There isn't a threshold where you become capable of working on crypto problems and code.

Making this safer makes mistakes far less likely and makes all of us safer.

Re: Should random() be banned?

#116

Post by Macha »

mmazing wrote: post #109
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 -…

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…

Because suitability for use in secure algorithms is just one property of the random number generator. At what point do we then decide it needs to be uniformInsecureBoundedRandom?

Why don't we apply the same logic to string comparisons. Should we replace String.equals with String.shortcuttableEquals()? Since there's plenty of circumstances where that is inappropriate for crypto uses also.

What about other functions with important caveats? Should we have mailGmailMightReject()? fsyncCantFixHardware()? file.existsAtCurrentInstant()?

Re: Should random() be banned?

#117

Post by MauranKilom »

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…

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

Re: Should random() be banned?

#118

Post by striking »

Macha wrote: post #116
mmazing wrote: post #109

Earlier quoted context omitted.

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…

Because suitability for use in secure algorithms is just one property of the random number generator. At what point do we then decide it needs to be uniformInsecureBoundedRandom? Why don't we apply the same logic to string comparisons. Should we replace String.equals with String.shortcuttableEquals()? Since there's plenty of circumstances where that is inappropriate for crypto uses also. What about other functions wi…

I actually don't hate `file.existsAtCurrentInstant`. `file.exists` is so misused.

Maybe functions suitable for crypto use should be in their own "crypto primitives" package.

Re: Should random() be banned?

#119

Post by TheCoelacanth »

striking wrote: post #118
Macha wrote: post #116

Earlier quoted context omitted.

Because suitability for use in secure algorithms is just one property of the random number generator. At what point do we then decide it needs to be uniformInsecureBoundedRandom? Why don't we apply the same logic to string comparisons. Should we replace String.equals with String.shortcuttableEquals()? Since there's plenty of circumstances where that is inappropriate for crypto uses also. What about other functions wi…

I actually don't hate `file.existsAtCurrentInstant`. `file.exists` is so misused. Maybe functions suitable for crypto use should be in their own "crypto primitives" package.

I would prefer something like file.existedAtSomePointInTheRecentPast

Re: Should random() be banned?

#120

Post by cperciva »

josephg wrote: post #70
mreome wrote: post #40

Earlier quoted context omitted.

There is a difference between generating these kind of IDs and writing the generator for these kinds of IDs. You shouldn't be rolling your own UUID generator if you don't fully understand the concerns/requirements in regards to your source of randomness. Generally speaking, I'd agree the need for a cryptographicly secure random is niche in that it is limited to the implementation of specific libraries/functions that…

I do this in nodejs all the time for IDs: require(‘crypto’).randomBytes(15).toString(‘base64’) Is this bad practice? Can you say more about why?

That's only 120 bits of entropy, which means that you'll get a collision after generating ~ 2^60 IDs.

Ok, maybe you're not worried about that scale; but I normally recommend 256-bit IDs in order to make sure that you don't need to worry about that possibility.

Post reply on HN