Hacker News Reader

Comment by otabdeveloper4 | Hacker News Reader

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

View on HN

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 of all that is holy, use cryptographic. This is basically every scenario where you are using random to generate an ID of some kind, and while it's only truly critical if that ID is all you need for validation, it does provide another layer of security even if you also require other information to match before giving out elevated access.

If the answer is "it defeats the algorithm I'm trying to do" (think something like ASLR, where you're randomizing the offsets of addresses so that attackers don't know where things are located), well, the reason why you need to use cryptographic should be blindingly obvious.

If the answer is instead "they can reproduce my results," well, you shouldn't use cryptographic in this case. And that's not a lot of cases: Monte Carlo simulations, testing, fuzzing are the obvious poster children for this category, and indeed reproducibility in these cases tends to be a highly valuable feature rather than an anti-feature.

Cryptographic random is almost never harmful to your application, and almost always provides some benefit in reducing guessability of your system. You should err on the side of using cryptographic random(), and only not use it when you are sure that guessability will not harm security in any way and you know that the cryptographic nature actively harms your application.

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 installed non-secure random() and if that's too slow consider other options.

Having a flag you can enable to warn about a non-secure random() usage, when it makes sense for your company/usage, sure. But banning it outright makes no sense, and the default behavior you want is very situational.

When it comes to optimization, there's a useful adage: make it work, then make it fast. Secure should really be seen as a necessary component of correct (and that it often isn't is a testament to the failure of our profession).

In that vein, the default random should be cryptographically-secure, with all the logic necessary to actually effect that security (e.g., not reusing seeds after a call to fork). You can also go ahead and provide an insecure random as well, but choosing the insecure random should always be something that the programmer has to go out of their way to do.

Secure should really be seen as a necessary component of correct security. I don’t see random() as part of security, and the problem is that people use it as such (that’s the failure of our profession as I see it). You wouldn’t want the default string equality operator to be constant time to prevent a possible timing attack, and in the same way I don’t think random() should be cryptographically secure by default. If you need secure random values, you are (should be) a domain-expert and should be selecting an appropriate cryptographically secure random generator from a security library, in the same way you would with a constant-time equality function.

I guess it's a matter of perspective over who random() is for. I see random() as for the programmers who don't know what kind of randomness they need, and don't need to know that because they just need something 'random' not something secure. I expect the domain-experts to know that it's not what they need. In my mind it's not that random() is not secure, it's that using it for something it's not intended for is insecure.

>When it comes to optimization, there's a useful adage: make it work, then make it fast.

When you need something to be fast, you better design it from the start to be fast. This is terrible advice for everything but some UI/web cases.

Speed is a feature. Not every feature can be just 'added' to existing code without changing most of it.

All of that is especially true for running simulations and the like. Whether these are fast is often determined by the architecture you decided on in the beginning.

Nowadays the world is full of libraries, frameworks, etc. that will never be as fast the competition, because they can't become fast without changing their APIs completely.

It's true that there's no one-liner you can use to sum up the whole field of software engineering, but that doesn't mean none of them are useful.

I completely agree that things which need to be fast should be designed structurally to be fast.

But which RNG function you use in a given function is about as far you can get from an architectural decision. You shouldn't need to refactor large swathes of your codebase to accommodate a substitution of one random number generator for a faster one.

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

Server-side folks generate random identifiers and shared secrets all the time. Yes, it's niche, but not "extremely" and you don't use a crypto library for this (you use secure random!)

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 despite being widely used, should NOT be frequently re-implemented.

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.

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.

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.

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.

Reply on news.ycombinator.com