Hacker News Reader

Comment by Macha | Hacker News Reader

This assumes writing crypto code is the most common use case for random numbers.

How often do you write crypto code?

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 security team implemented an automated vulnerability scanner in our github enterprise instance, and it spammed comments and marked a review as requiring changes if it edited any merge request which touched a file which used java.util.Random. It lasted a day before the security team was made turn it off as on our team (and many others), literally 0 uses of random numbers were those requiring a secure random.

View on HN

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.

I disagree.

Making one specific aspect of incompetent crypto coding “safer” doesn’t solve any of the problems.

We can argue about what threshold you need to reach to be considered “capable” of writing crypto code (that’s not just a learning exercise), but not knowing the deficiencies of random() is clearly well below that bar. Even knowing that is barely past the “don’t eat your crayons” level of skill.

If anything, a hook in your CI pipeline that automatically fires anybody who checks in code using random() in a cryptographic context is a better way to “make all of us safer”.

You could be a great mathematician and not realize what kind of random you're picking. It's not as simple as you put it.

This discussion goes for other stuff too. Rust is getting popular because even amazing C and C++ devs make terrible mistakes that cause severe security and privacy problems down the line.

Just because someone is a great mathematician does not mean they would be a great cryptographer. Mathematics and cryptography are about as related as computer science and cryptography (not that much).

> should they be

This is the point of people suggesting things like bans or explicit warnings. They "shouldn't", but what's stopping them.

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

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.

Yep, there's no rule of thumb that can spare you from reading the docs and knowing basic things about the code you're about to pull in.

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.

You’re right I’d just looked at the rail implementation. I was basing it on my past knowledge of windows GUID implementation.

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.

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

Because for well over 99.99% of developers, cryptography is a “niche application”.

I’ve never written crypto code I’ve deployed anywhere. If I need crypto, I use the highest level crypto library I can find that people I trust who _do_ know about crypto recommend.

The only time I ever recall non cryptographic random() functions to have surprised or affected me was way back when I discovered if you forgot to seed the random on an AppleII the games I wrote in Basic all started out with the same “random” choices.

Cryptography is rare, but generating other data that needs to be unpredictable (e.g. session IDs, password reset tokens, random passwords getting generated, gift card codes, real-money gambling numbers) is quite common, I think.

And the default implementation of random() doesn't seem to be any faster than AES-CTR (which is the core of one form of secure PRNG).

It's true that most people who aren't doing sensitive work don't need cryptographically secure random number generators, but if you use something secure by default, it probably won't cause problems, and to the extent that it does you can catch them with some profiling. If you use insecure RNG by default, it probably won't cause problems but if it does you'll find them when a black hat hacker compromises your system in production.

Very few people set out to roll their own crypto. The issue in my experience is less about someone writing their own hand-optimized password hash function and more about people having overly-narrow views of what counts as security critical code.

The problem is the “banning” things as suggested in the article leads to bullshit like FIPS 140-2 mode.

So MD5 hashes are disabled in the system library for applications where it is not presenting any meaningful risk, for example. The other issue is that bans usually come with lists of things are not aren’t banned. So now you are stuck with waiting for some disinterested committee to support something that delivers a benefit.

Use the minimal amount of resources and scale up. If you need mostly random don't force cryptographic level random. It adds unnecessary processor cycles and reduces speed.

I benchmarked it, and AES-CTR is faster than `random()` on a machine with AES-NI.

That's my main point: It does _not_ seem to be meaningfully more expensive to use cryptographic randomness. Yes, you could build a faster non-cryptographic PRNG, but that's not what is done by the default library.

The most common case for me is when fuzzing, when I want reproducible random numbers, so it must be possible to initialize the RNG from a known fixed seed so that I can re-run and debug a failure.

Hence my suggestion to use a deterministic cryptographic generator: This way, you can either get "proper" randomness by seeding it with a random value, or predictable (and yet strong against anyone who doesn't know the seed) randomness by seeding with a fixed value.

> It lasted a day before the security team was made turn it off as on our team (and many others), literally 0 uses of random numbers were those requiring a secure random.

can concur, currently approaching 400k SLOC of C++ in the repo. A few dozens different places crop up where random is needed (with a quick and dirty grepping). Literally 0% is for secure stuff. Most of it has to be as fast as possible (and very low quality, as it just needs to be random / noisy enough to look random for human perception)

This just kind of proves GP's point. Random APIs usually tell you what the RNG is, but not the why/how. Most people don't care if it's /dev/(u)random, Mersenne twister, PCG, LFSR, LCG, RDRAND, etc. They care about roughly 4 attributes:

- Is it good for crypto

- Is it fast

- Is it reproducible

- Is it portable

But fundamentally, it's about the use case and interface:

- I need secure random (strong, slow, secure)

- I need Monte Carlo (good enough, fast, reproducible)

- I need chaotic behavior for my game/stress test/back off protocol (usually can be barely random, fast, reproducible)

I think calling the last case InsecureRandom or RandomEnough is reasonable to convey "don't use me for secure purposes".

Interestingly a major aspect of video game speed running is figuring out how the game generates random numbers then exploiting the knowledge. For example speedrunners avoid all random battles in an rpg with this tactic. I'm not arguing games need true random for the record.

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.

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()?

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

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.

It's more pleasant because it is less random. I naive implementation might use true randomness which to a human doesn't appear random.

https://www.businessinsider.com.au/spotify-made-shuffle-feat...

Right, I'm not disagreeing with that.

But I bet that the main goal is not "Let's make this change so it sounds more random, and then people will like it because they think it's randomer." Rather, it's "Let's make this change so it sounds better, and also as a side effect people might think it's more random."

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.

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

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

How many of those applications are ones where a single AES encryption is too slow?

Did you mean to reply to my comment?

I don't disagree with anything you say, but it also doesn't refer to my comment.

Why not? I feel the same about naming a method to shame/discourage use as you suggested for outright banning. It shouldn't require a justification to use non-CSPRNG, because most use cases I run into for random are not crypto, because I don't write my own crypto.

Reply on news.ycombinator.com