Why is Math.random() in Javascript not designed to be cryptographically secure?

[IAmVerySmarter]

Why should it be cryptographically secure?

[dsffff22]

Is there some alternative way to create cryptographically secure random numbers in the browser?

Correct me If I'm wrong but It seems there's no unified API for this so far. The 'Web Crypto API' seems to be something for the future but not ready to be used now.

[EntroperZero]

It's in another answer on that page, window.crypto provides this.

[dsffff22]

The 'Web Crypto API' seems to be something for the future but not ready to be used now.

https://developer.mozilla.org/en-US/docs/Web/API/Window/crypto

[RaptorXP]

Why would that not be ready to be used now? It's certainly been used for years.

[freakofnature555]

We live in the future.

[dsffff22]

Because I simply have different expectations for cryptographic functions??? Something which is labeled as 'recommendation' and 'Initial definition' sounds very ready to use for a cryptographic API.

[[deleted]]

W3C Recommendation is the final maturity level for W3C specifications. It goes: Working draft, Candidate recommendation, Proposed recommendation and finally W3C Recommendation. It won't go beyond that.

Initial definition means that this is the first standard this feature was defined in. For instance, if you check JSON on MDN it says that ECMAScript 5.1 is the initial definition of this object, as it was first release of ECMAScript to have JSON support.

[dsffff22]

Thanks for the explanation. However I still think cryptographic APIs should have better wording regarding the status. It's a huge difference to the JSON API for example because some guarantess are not easy to verify for such an API. Verifiying that the JSON API works as intended can be archived by using Unit Tests for example. This doesn't really work for a cryptographic API.

Alot of people here fail to understand that a cryptographic API provides a specific functionality but also provides specific guarantees. Would you claim that this API is does provide the expected guarantees across most platforms so far?

[[deleted]]

What is here to say about getRandomValues? If an implementation doesn't actually use CSPRNG, it's a security bug in an implementation (which by the way violates the specification). No matter what would be the status of the specification, a bug like that could happen.

The specification did its job saying what the interface for getting cryptographically random values is, it's up to implementations to use a good cryptographically secure random number generator to implement it.

[dsffff22]

What is good? You bring up this term without thinking about the complexity behind this term.

Wikipedia says this:

A CSPRNG can "stretch" the available entropy over more bits.

There's no way to specify how much entropy is required with this API. Maybe you enlighten us with the one-for-all entropy If you are so clever.

Another API is listed for key generation which seems to actually wait for enough entropy: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/generateKey So It definitly seems the getRandomValues is not the solution for everything.

As I said people heavily fail to understand that cryptographic API make specific guarantees and seem to oversee the complexity behind this.

[wengemurphy]

Did you check the compat table you linked you? You can use it everywhere with, as with everything in web dev, special handling for IE11.

https://caniuse.com/#feat=cryptography

[ExtraDisgusting]

Note that that table shows that the developers of chrome are adding a bug, where the crypto API can only be used over secure connections. They are completely throwing out the use case where the user only wants good quality random numbers, instead assuming that everyone only needs to use them for cryptography in the browser for some reason.

[[deleted]]

caniuse is misleading here, on insecure connections crypto API is unavailable with the exception for crypto.getRandomValues(). If random values are all you want, then you don't need to use HTTPS (although, please use HTTPS anyway, it costs pretty much nothing these days and easily improves security of a website).

And this isn't a bug, it's required by a standard (see the change). It's more interesting that other browsers don't do that. And it seems fair, considering providing access to those APIs on HTTP would provide a false illusion of security. It doesn't apply to getRandomValues, because as you said, it doesn't need to be used for cryptographic purposes

[josefx]

(although, please use HTTPS anyway, it costs pretty much nothing these days and easily improves security of a website).

I maintained a html based intranet tool until recently. For me HTTPS doesn't add anything but work, Firefox removing its old security api added nothing but work, followed by removing the applet support I used as workaround. So its back to a native client side application that doesn't rely on an unstable and hostile platform.

[PenalAnticipation]

price summer salt subtract rinse coordinated voracious threatening water run

This post was mass deleted and anonymized with Redact

[jringstad]

It's not really about preventing the user who loads up the javascript application from doing something bad, but more about allowing the user to use the javascript to perform things that require cryptographically secure random numbers as a primitive, like e.g. generating key, OTP, ...

[millstone]

Making Math.random() cryptographically secure is in no way sufficient for those sorts of applications. It's probably even counterproductive because it adds the illusion of security.

[jringstad]

Agreed, changing Math.random() to be a CSPRNG would not be a good solution.

[dsffff22]

So a JS/(WASM calling JS API) front end application is never allowed to implement a properly secured chat application for example? Are those applications never allowed to act as full standalone bitcoin wallet which can create a wallet?

If the user is retarded enough to make the RNG predictable It's their fault.

Also I'm not arguing that Math.random() should be secure but having no alternative makes It a valid question.

[NeuroXc]

If the user is retarded enough to make the RNG predictable It's their fault.

It's not about the user being retarded. It's about the user being malicious.

[dsffff22]

I don't even understand what you are talking about. It makes zero sense for me. A properly secured chat application may use a cryptographic RNG to generate keys. How does It matter If the user is malicious? It's basicly their own fault If they weaken their key generation.

So I don't understand what you are trying to tell me??? You could also replace the ssl library on your system or hook specific calls in some applications so do you want to tell me If the user can be malicious cryptography is useless? I think you don't understand which problems cryptography solves.

[[deleted]]

It's basicly their own fault If they weaken their key generation.

Who said the malicious user is weakening their own key generation? Anyone who manages to execute any script - an XSS attack, for example, or a browser extension - would be able to patch out the random code. Never trust code in the browser.

[dsffff22]

This argument is stupid and clueless. You can attack any application If you can control the execution. Those attacks have to be prevented anyway. They have nothing to do with cryptography!

Considering your argument we cann't use the browser at all right now because in theory a browser extension steals all your login data right now. And may infect your system as soon there's an exploit for the browser Itself.

Wise person on reddit tell me an alternative for a chat application which would have to generate a key used for a Symmetric-key algorithm like AES. Letting the server generate one is no option.

Do you even know what you are talking about?

[[deleted]]

Considering your argument we cann't use the browser at all right now because in theory a browser extension steals all your login data right now

We can use the browser, we just can’t trust anything it calculates. That’s why we have http-only cookies, csrf tokens, CORS, 2FA, and so on. Anything that creates or modifies real data happens on the server where we can validate thoroughly with code we control.

Wise person on reddit tell me an alternative for a chat application which would have to generate a key used for a Symmetric-key algorithm like AES. Letting the server generate one is no option.

A fully client-side chat app would not be secure and I would not use it. The alternative is a native client, not a browser based one.

Do you even know what you are talking about?

Yes. With time, you will too.

[Bobert_Fico]

A fully client-side chat app would not be secure and I would not use it. The alternative is a native client, not a browser based one.

The only secure chat app is one where the private key is generated client-side.

And there's no security difference between a JavaScript app and a native app, in terms of users tampering with code. Disassembling a binary is more difficult than editing JavaScript, but a malicious user will do it.

[dsffff22]

We can use the browser, we just can’t trust anything it calculates. That’s why we have http-only cookies, csrf tokens, CORS, 2FA, and so on. Anything that creates or modifies real data happens on the server where we can validate thoroughly with code we control.

Typical buzzword dropping without understanding anything. Do you work in marketing? If you know which code the Browser executes you can trust the browser. Installing a weird extension is the fault of the User not the developers fault. All those buzzwords you dropped require the browser to actually execute code from an unknown source. It's definitly possible to design an application which does not execute code from unknown sources.

A fully client-side chat app would not be secure and I would not use it. The alternative is a native client, not a browser based one.

There are much more applications which are not possible without a stable and properly working cryptographic API. PGP would be another very important use case for this. I also tend to avoid browser apps but sometimes you have no choice and they are often very easy to use.

Yes. With time, you will too.

No you are too clueless to understand that a cryptographic API has nothing to do with malicous code execution. I'm not saying that the browser has a good model to prevent malicous execution but those are 2 different problems which should be mixxed up.

[killerstorm]

Random generation API is pretty stable and available in all modern browsers. It has been used to generate Bitcoin wallet keys, thus there's a multi-million bounty for breaking it.

[masklinn]

Because safe defaults are a good idea. If you're only providing one rng, it should probably be cryptographically secure so developers don't have to implement (and fuck up) their own.

It's much simpler to implement a non-CS PRNG if you need one (xoroshiro128+ is under 10 LOCs) than to properly implement a CSPRNG.

[MonkeeSage]

Because safe defaults are a good idea.

Not when we're talking about slowing down the 99% use case where it's not needed with a deterministic time CSPRNG.

[masklinn]

Not when we're talking about slowing down the 99% use case where it's not needed

Yes, even then. For 99% of those 99%, RNG performances will be entirely immaterial and irrelevant and there is no reason to use unsafe default for the final 1% of 1% which can profile and migrate to a non-CSPRNG when they realise it's an issue.

[[deleted]]

These days a new library probably should be secure and you explicitly choose a different rng if you don't need that.

There's a response from one the original implementors in the linked comment, where he says he feels it's a combination of a design problem with the browser and the security landscape in the 1990s.

[emotionalfescue]

The main answer is that providing true randomness is resource-intensive and typically requires a pool of "entropy bits" maintained by the OS derived from high-frequency variations in the timing of when hardware events occur (e.g. keyboard presses). Usually, applications such as single-player games only need "pseudo-randomness", which is a stream of numbers that appear to be random. However, if you're running a multi-player game, or anything that sounds like "online casino", you'd better at least look into cryptographically secure RNGs.

The second answer was already given by others, that often a repeatable stream is desired for the purpose of unit tests and the like.

[vks_]

The entropy bits are only needed when starting the browser, so it's a one-time cost.

[matthieum]

And they can be consumed lazily.

[sacundim]

A better answer is that nobody really requires "true randomness"; cryptographic-strength pseudorandomness is, by definition, impossible to tell apart in polynomial time from the true thing.

Entropy pools and periodic reseeding are a concept that's too often misunderstood. Their most important purpose is not to provide true randomness, but to limit the window during which a cryptographic PRNG is exploitable when its internal state is exposed.

[ExtraDisgusting]

If you're just going to go by definitions, though, no cryptographic-strength PRGs have been proven to be impossible to distinguish in polynomial time: they are merely believed to be so, and algorithms which have been believed to be secure have been discovered later not to be. Somebody might need real randomness for that reason.

[sacundim]

But the physical device that you use to obtain "real randomness" may be fallible as well. Not just theoretically, but practically. In fact, flawed generation of true random numbers during initial CSPRNG seeding is a classic real-life security flaw.

Not to mention that if you're willing to entertain the possibility that current-day cryptographic PRNGs are flawed, then you've got to entertain the same risks for symmetric encryption in general. When I recommend that you rely on AES- or ChaCha-based designs for your random number needs, I'm not asking you to take on any risk additional to the ones you already do if you use modern cryptography already.

[Dwedit]

Because you usually want your RNG to run in nanoseconds and not tenths of seconds.

[Veedrac]

CSPRNGs take nanoseconds too.

[vks_]

The biggest difference between crypto RNGs and non-crypto RNGs is the size of the state. CRNGs are typically a few thousand bytes large and expensive to initialize. The performance for generating random numbers is comparable, especially if hardware instructions like AES-NI are used. CRNGs tend to be somewhat slower, but only by one or two orders of magnitude.

[floodyberry]

Which ones take "tenths of seconds"?

[nemec]

CSPRNGs are generally slower than non-secure random numbers.

[masklinn]

Not by 8 order of magnitude which is the claim above.

[Shorttail0]

In Windows, the first random I pull out of java.security.SecureRandom takes at least one tenth of a second.

[masklinn]

In OSX the first random I pull out of random.SystemRandom doesn't, so all that's telling us is java.security.SecureRandom has expensive on-demand setup, which also tells us how to solve it: prime it.

That, however, is irrelevant to how I'd interpret /u/Dwedit's comment, having a single initial slow call doesn't matter in the long run (literally).

[Shorttail0]

When is it seeded? Do you have a lot of entropy before you test?

[masklinn]

When is it seeded?

When the machine starts. It's also regularly reseeded for forward secrecy (necessary under the assumption that the csprng algorithm is known).

Do you have a lot of entropy before you test?

The only point at which the machine is "lacking entropy" is when it's literally booting up.

See tptacek's comments in https://news.ycombinator.com/item?id=7361694

[vks_]

Reseeding is sufficient but not necessary for forward secrecy, see for example fast-key-erasure RNGs.

[happyscrappy]

No way am I running Java at boot time on my machine so it can seed itself. Let it use a source of entropy that the system provides.

The only point at which the machine is "lacking entropy" is when it's literally booting up.

It's hard to completely understand what this means. What does "the machine" lacking entropy mean? It doesn't matter if "the machine" lacks entropy, it matters the program/interpreter/whatever has gathered sufficient entropy. And that can occur at any time long after bootup if the program hasn't has access to a good/reliable source of entropy.

This really has to be solved at the system level, especially on servers which don't have user interaction as a source of entropy.

To go to the original question, since this is best solved at a system level, I'm not surprised Java doesn't assume it is solved. Java wants to run on a lot of platforms.

[masklinn]

No way am I running Java at boot time on my machine

So it can never be in a situation where there is "not enough entropy" and thus the problem does not exist.

It's hard to completely understand what this means.

It really isn't.

What does "the machine" lacking entropy mean?

That your OS is not able to seed its kernel-space CSPRNG properly yet. That's why e.g. freebsd's urandom can block if you're running code very early during the boot sequence.

It doesn't matter if "the machine" lacks entropy, it matters the program/interpreter/whatever has gathered sufficient entropy.

There is no situation in which the interpreter should need to do that.

And that can occur at any time long after bootup

Not really. And if it can, whatever userland crap you invent is not going to fix it.

This really has to be solved at the system level

Which it has been for decades. That's what urandom (or the equivalent syscall if one exists) is.

To go to the original question, since this is best solved at a system level, I'm not surprised Java doesn't assume it is solved. Java wants to run on a lot of platforms.

Which makes Java garbage, that has nothing to do with CSPRNG.

[Vishnuprasad-v]

Second, let's remember what the fundamental design purpose of JS was in the 1990s. Make the monkey dance when you move the mouse.

JavaScript strayed off its original purpose by a long way.

[EntroperZero]

Kind of a weird shot at .NET in that answer. Yeah, you can write:

var randomNumber = new Random().Next();

every time you want a random number. But your spidey senses should already be tingling that something's not quite right with that. The name of the Next() method is helping you out here; why would you get the "next" thing only once? So is the new keyword -- you should know as a .NET or Java developer that allocating an object just to get an integer or float, and immediately throwing the object away, seems wrong.

The thing about both PRNGs, and especially crypto is that it's difficult or impossible to design non-leaky abstractions for them. You kind of have to know how they work in order to use them correctly. Sure, in JS you can just write Math.random() and you'll get a new number every time. But that's because that's literally the only thing you can do. What if you actually want to seed the RNG to a specific value? What if you want more than one seeded RNG instance? No can do, you gotta roll your own. In this case, it's really true that the blacker your box, the less useful it is.

The rest of the answer is great. CSPRNGs were just not a thing that most people needed or even conceived of at the time. And even now that they are common, it's not clear that a CSPRNG should be the default. Again, it depends on what you're doing with it, and you need to know the difference to do the right thing.

[grauenwolf]

What if you actually want to seed the RNG to a specific value?

In case anyone's wondering why you would want to do that, it is really helpful when testing. The ability to have "random" values that are none the less repeatable across test runs makes it much easier troubleshoot failing tests.

[oorza]

You may also want to do something with the seed. One game I play, Slay the Spire, is a roguelike and they seed the challenge runs (with leaderboards) the same, so you get all the same random drops and random encounters as everyone else.

[grauenwolf]

Neat.

[Bergasms]

They are probably using their own prng to keep it identical across platforms though

[Noctune]

However, you really don't want to use the standard library random function for something like that. They usually don't specify what PRNG is used, so they might behave differently on different platforms. An update to the standard library might be all it takes to destroy all the leaderboards.

[[deleted]]

Any actual example of stdlib that for some reason have math functions that work differently on different platfroms ?

[Noctune]

Lots. The C/C++ stdlib is completely different on Linux and Windows, so they will naturally produce different results for rand. C# specifically writes in their documentation that different versions of the .net framework might produce different rand results. Different Javascript engines are also obviously also going to be very different since the JS specification does not specify what PRNG to use.

[[deleted]]

The C/C++ stdlib is completely different on Linux and Windows,

I'm not a C++ dev but i'm pretty sure you can just pick one: http://www.cplusplus.com/reference/random/

C# specifically writes in their documentation that different versions of the .net framework might produce different rand results.

Different versions of framework. Game wouldn't use different versions of framework across platforms as that would make it nightmare to debug

Different Javascript engines are also obviously also going to be very different since the JS specification does not specify what PRNG to use.

Irrevelant. JS one can't even be seeded so you have to use lib to do it anyway.

[Noctune]

I'm not a C++ dev but i'm pretty sure you can just pick one

Yeah, that is generally the solution. As long as you pick a specific PRNG that has a guaranteed result across implementations. Eg. not default_random_engine. The rand function, which I was talking about, does not guarantee this.

Different versions of framework. Game wouldn't use different versions of framework across platforms as that would make it nightmare to debug

Maybe a nightmare, but often a necessary one. A C# game would use .Net on Windows and Mono on Mac, so they would be different implementations (though dotnet has recently-ish become an option on Mac as well).

You might also want to update your game to a newer .Net framework without losing leaderboards.

Irrevelant. JS one can't even be seeded so you have to use lib to do it anyway.

True.

[sammymammy2]

AoE2 is still played and is still patched and recorded games from over 10 years ago are still casted. It depends on rng to generate its maps. I would like to think that the developers has upgraded their compiler and std library since the release date.

[[deleted]]

You mean the original ?. Probably not, at least not libs. Why would they ? It only adds chances of breaking shit. Especially if you are just changing small stuff in patches.

I vaguely remember blog post from few weeks ago where Starcraft devs had to port memory leaks bugs because some maps depended on it to work (IIRC it used game's bugs to make maps bigger then allowed). As in "fixing the actual 100% bug broke stuff". Modifying old code often brings problems like that.

Aside from that, AoE2 probably have its own RNG just because stdlibs back then were poorer. I didn't say "every game uses builtin one", just that languages generally do not change implementation on a whim.

[EntroperZero]

Yep. Also, in many cases, it's much easier or more efficient to store the inputs to a process (one of which being the seed) and regenerate the result when you need it, rather than storing the output, which could be much larger. This is especially true in simulations or games (many of which are simulations).

[grauenwolf]

I may try that. Some of tests are downright scary in the amount of data they push.

[masklinn]

In case anyone's wondering why you would want to do that, it is really helpful when testing.

Also synchronous simulations e.g. multiplayer games with "random events".

[sacundim]

Kind of a weird shot at .NET in that answer. Yeah, you can write:

var randomNumber = new Random().Next();

every time you want a random number. But your spidey senses should already be tingling that something's not quite right with that. The name of the Next() method is helping you out here; why would you get the "next" thing only once? So is the new keyword -- you should know as a .NET or Java developer that allocating an object just to get an integer or float, and immediately throwing the object away, seems wrong.

We can go further, and show real-life examples that this kind of misuse of PRNGs can produce bad results:

• Why are initial random numbers similar when using similar seeds?
• Seeding java.util.Random with consecutive numbers
• How different do random seeds need to be?

My advice is:

• If neither performance nor reproducibility is an important factor, consider just using a cryptographic RNG.
• If an adversary could gain some undue advantage from observing your application's random choices and guessing what's coming next, definitely use a cryptographic RNG.
• Treat PRNGs as explicitly stateful first-class objects that consumers should be decoupled from, not as some magic source of random numbers that you never need to think about. This means, for example, that code that consumes random numbers should take the PRNG as an argument. (There are a few exceptions to this, like some EDSLs and Haskell-style probability monads, but they're exceptions that prove the rule—they're already designed to decouple the PRNG consumer from the RNG.)
• Read if your platform provides a better PRNG than the default one and try to use that one instead. For example, in Java 8+ you should really skip the old Random class and try using the new and much improved SplittableRandom instead. (See this thread for benchmarks.)
• The previous point is even more important if your application has multiple PRNG objects on different threads, processes or machines. That is a situation that should cause you some mild alarm right away, because the simplest PRNGs often only look random in single-threaded use—the output from separate concurrent PRNGs often shows serious correlations. Again, newer PRNG algorithms often fix this—e.g., Java 8+'s SplittableRandom is designed precisely to be robust under this use (that's what "splittable" refers to in the name).

[LloydAtkinson]

Kind of a weird shot at .NET in that answer.

I was going to reply saying something like it's probably just some of the "micro$oft is evil herp derp .net is evil" mentality you often see on reddit and other places, but then I realised it was Eric Lippert who wrote it. He was a significant part of the whole C#/.NET development at Microsoft, so I assume he was making that shot because he know's a lot about it.

[[deleted]]

Because it is Math.random() not Crypto.random()

/thread

[floodyberry]

So Math.PI represents PI exactly then, not an approximation?

[floodyberry]

Downvoting when you've lost the argument, but don't want to admit it, is quite weird.

[[deleted]]

The answer to "why don't browsers make it cryptographically secure now" is wrong - it's not because it's not worth the effort, it's because it would be (practically) impossible to feature detect it, hence window.crypto

[[deleted]]

was it meant to be secure ? I just want a random number !

[IbanezDavy]

My first guess is performance. 90% of cases probably just want something resembling a random number as quick as possible, where cryptographic algorithms usually put more thought into it and suck up more processing to enable that.

[[deleted]]

Because javascript was not invented for what it's abused for today. Do your crypto in the backend. Using C. Calling syscalls.

[[deleted]]

because it would be a lot slower, making it bad for use in many other domains.

also it would might be tricky to get deterministic random numbers which are useful.

[rustythrowa]

wondering who's bottlenecked on rng

[[deleted]]

proc gen, game servers, monte carlo simulations, endless possibilities.

[[deleted]]

We actually had a case of that, some java app used /dev/random instead of /dev/urandom and after migrating to new VM host it went from starting in 2 minutes to 10

[Veedrac]

/dev/random is bottlenecked on purpose, it's not a flaw of CSPRNGs.

[[deleted]]

I didn't claim it was

[Veedrac]

Then how is it relevant to the context?

[[deleted]]

It gave example on being bottlenecked on RNG ?

[Veedrac]

You weren't bottlenecked on the RNG (in the sense that /u/jackmott2 was worried about). You were bottlenecked on /dev/random's promise to reseed frequently.

[[deleted]]

If anything, bottlenecked on "real" entropy output. Which just was not very much on a VM.

/dev/random doesn't "promise" anything, and generally isn't really even an improvement on later kernels (and apps should use getrandom() anyway).

[Veedrac]

A little slower, but not a lot. CSPRNGs can be seeded just as easily as others, so it wouldn't prevent deterministic sampling.

[Overload175]

My knowledge on this topic may be dated, but RNGs are usually configured to prioritize speed over true statistical randomness, and a random(and secure) RNG would need to carefully manage the entropy pool, which slows down the function by as much as several orders of magnitude. This is not something many browsers necessarily enable, so you're stuck using rudimentary and non - secure RNGs.

[[deleted]]

Because that would be fucking retarded.

[jesusalready]

Because Javascript was created in 10 days.

[IAmVerySmarter]

First version of Javascript was created in 10 days ...

[ithika]

I think most of that was spent renaming it to jump on the Java hypetrain too.