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 iCopyPastedThisFromStackOverflowRandom()?
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 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.
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)
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.
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.
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.
Making this safer makes mistakes far less likely and makes all of us safer.
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”.
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.
It isn’t random is the problem and they are are used everywhere as a secret. People think they are random 122bit value.
This is the point of people suggesting things like bans or explicit warnings. They "shouldn't", but what's stopping them.
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.
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()?
Maybe functions suitable for crypto use should be in their own "crypto primitives" package.
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.
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.
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.
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.
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).
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.
What is appropriate to use comes down to context.
https://www.businessinsider.com.au/spotify-made-shuffle-feat...
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."
I don't disagree with anything you say, but it also doesn't refer to my comment.
- 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".
So make random() a CSPRNG (and an alias for SecureRandom() for people who want to be explicit) while InsecureFastRandom() is just what it says and has no other name. Then if you really need performance over unpredictability, it's there, but nobody is confused about what they're getting. And lazy people who don't like to type or pay close attention get the safe one.
random() should be the most universally applicable random which includes making it as secure as possible. Non-universally applicable randoms should be named accordingly.
For most domains secure random is a niche, not universally applicable.
The vast majority of people reuse low-entropy passwords, figuring out what password generator someone used would be a much higher bar than figuring out passwords, and just knowing the insecure generator wouldnt reduce the entropy by that much.
Actually, a password generator on GitHub that generates the password that is literally just seconds-since-1970 would still be a good generator for almost all use cases.
I think if there's any gap it would be wrong roll your own password generator at all and you only use ones authored by security experts: just using SecureRandom instead of Random isn't going to somehow magically guarantee you didn't mess up another way and write a low-entropy password generator.
:facepalm:
Seriously.
Here are the last several times I saw random() used.
Seeding a neural network for a Coursera course. Not only do you need to call random() a bunch of times, but the ability to set a seed and get deterministic results makes grading of the results massively easier.
Creating simulation data used for integration tests on a piece of software.
Picking a few random numbers that I used in an explanation of an answer.
Of course the plural of anecdote is not data. However in my corner of the world it is very rare to need cryptographically secure anything. And when I do, I know better than to code it myself. But it is common to need a lot of cheap numbers in a hurry.
Only 7 rounds of chacha are cryptographically broken, so chacha20 has excessive security margin. Using 8 rounds of that everywhere you use random today (and not a CSPRING) should be a no-brainer, I guess.
On hardware with AESNI (like all x86 for the last 10 years), a reduced round AES-CTR should be very fast and also string enough for the cases when you don't need a CSPRING. Full AES-128 outputs 4.7GB/sec on my laptop, recent chips have better AES throughput.
The parent comment said "Most simulations, games ...". Most. Not all. I think it's pretty obvious that Poker would not be included a statement of "Most".
The real litmus test is the question of "What happens if a malicious actor is able to predict the random numbers?"
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.
* 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 have a crypto default random, better to at least have a really good and really fast one.
[1] https://en.wikipedia.org/wiki/Mersenne_twister
[2] http://www.math.sci.hiroshima-u.ac.jp/m-mat/MT/ARTICLES/mt.p...
So given that Mersenne Twister sucks in pretty much every possible way other than having a catchy name, likely the sole source of its continued popularity, its probably not a good choice for replacing some "default" random number generator with something better.
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.
https://nullprogram.com/blog/2017/09/21/
I don't think better randomness than MT is as high a bar as you make it out to be, both links above also briefly mention statistical shortcomings of MT.
Mersenne Twister is not secure, and it isn’t a very good RNG even for insecure uses.
I used to be able to play about a dozen Pac-Man levels knowing exactly where every ghost was going to go and every bonus that was going to appear. And I wasn’t a very good player.
Pac-Man would have been a less fun game for many people if it used crypto grade random.
I’d bet a lot of money that the number of times random() is used in a non cryptographic context is many orders of magnitude higher than the use of random numbers in crypto code. That make non crypto use “the most universally applicable” case.
I would also agree that “non universally applicable random” such as those used in crypto code should be named accordingly. Which they are. Secure_random() is the right choice for the vanishingly small number of developers writing crypto code. random() is the right name for pretty much everybody except those who need to know a lot of other crypto-specific other things as well. They can’t use random() the same way the cant use non-constant-time comparisons and algorithms that leak side channels via power monitoring or cache hitrates. Fixing random() and letting people who don’t know they should have been calling secure_random() write code in niches they don’t know enough to get everything else right, is without doubt going to end up with way more code that is not “as secure as possible” even if it happens to use secure random numbers.
The thing is, if you need random numbers fast, then profiling will tell you "Opps, used random() when I should have used fast_random()". That's an easy change to make that'd show up in profiling if performance were an issue.
If random() never comes up in profiling, why care that you are getting the secure version?
The danger of missing "secure_random()" is that it creates a security vulnerability (Potentially leading to loss of money, information, etc). The danger of going the "fast_random()" route is that your application will run slower potentially leading to a dev needing to spend time to swap in "fast_random()" for "random()". That, to me, doesn't seem like a major problem or risk.
Programmers are notoriously bad at predicting when something will end up being a performance issue. So why preoptimize because we assume most people want/need speed?
“Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...
Which will then be conspicuous enough for the developer to notice and fix it.
> “Lazy people who don’t want to type” are not the sort of people I want writing the code I might use or interact with that requires cryptographically secure random numbers...
Bad news though.
https://searchfox.org/mozilla-central/rev/3ff133d19f87da2ba0...
Rust's "unsafe" is a pretty bad name and completely different reasoning behind using it. It doesn't mark something as "dangerously unsafe, don't use", to a consumer it indicates "exercise caution" and to a compiler it just allows 5 things:
Dereference a raw pointer
Call an unsafe function or method
Access or modify a mutable static variable
Implement an unsafe trait
Access fields of unions
`dangerouslySetInnerHTML` is literally dangerous and allows XSS if used with outside input.
It also is faster than the other variant. The same is true for `random()`. Both can be used when you know what are you doing to gain some performance.
Meanwhile, `unsafe` rust by itself is not different from safe rust in terms of speed. You have no choice, but to use it places it supposed to be used.
The word 'safe' in Rust has a very specific, technical meaning. 'unsafe' is simply code that is not automatically 'safe' in the Rust sense.
A non-Rust developer sees safe/unsafe and gets worked up, but that just means that he should put his rust-colored glasses [*] on.
This is not unusual in ICT, known for its colorful language. A non-ICTer hears 'black hat' and thinks about how cool and stylish the hat is. An ICTer hears 'hacker' and thinks about how cool and stylish the hack is.
[*] Thanks, Raymond!
Likewise `unsafe` marks areas where you need to be really careful that you upholding the safety invariants yourself, whereas in normal Rust code you don't need to think about that at all.
It's probably okay to leave the function as it is and just drill into people that if you're doing cryptography, you either need to know exactly what you're doing all the way down to the hardware or you need to leave it a task for somebody else more specialized than you. I, for one, never assume random() is cryptographically secure, but it might be because I grew up programming during the era where random was computed off of clock cycles since CPU startup because there wasn't much other cheap entropy to lay a hand on ("battery-backed onboard date clock?! Oh, look who has AKERS money!").
https://hackage.haskell.org/package/bytestring-0.11.0.0/docs...
Gets the point across and will still work when I'm long gone.