There's Math.random(), and then there's Math.random() (2015)

> I learned in college that most random number generators use the current timestamp to generate a pseudo-random number.

> How does this differ cryptographically from algorithms like MWC1616 and xorshift128+ in backend applications?

That question doesn’t make any sense. The current timestamp would be a seed to initialise the PRNG, which can be MWC or xorshift.

> Does it really matter which random number generator you use on a webpage?

That is application dependent. If you’re coding a roulette wheel no, if you’re coding an E2E chat yes.

> It's already considered an insecure environment anyway (that's why we have server-side validation).

That is also application dependent. The client is considered insecure from the server pov because it is entirely under user control, so the user can mess with anything. But if it is acting entirely on behalf of the user then that can be the point and by design.

In the example above, you don’t care that a user fucks up their own crypto, but you do care that the crypto holds for the average user.

Even the qualitative difference between two non-CS PRNG can make or break a project due to too small a state space or short a cycle.

In a class we had to reverse-engineer an application that had encrypted some text file — we had to decrypt it without the key. Turned out the application just used the current unix timestamp as the key. A brute-force search of the past few months didn't take very long.

If you include nanoseconds in your key then you have more entropy, of course, but timestamps are guessable, so it's risky.

One attack might be exploiting One Time Passwords. Lets say you send yourself enough tokens to calculate the state, you will then be able to calculate the next token and login as another user. However that should be easily fixed by adding some salt relating to the user, meaning you would only be able to figure out _your_ next token.

You can go back into a time before computers and use the most famous examples of how bad RNGs endanger crypto: One Time Pads (OTP). This is basically just a XOR of your message with your random numbers. If your random numbers are bad they leave patterns in the XOR-ed message that can be statistically analyzed and potentially decrypted.

Bad PRNGs repeat early and have predictable patterns, as such they form a special attack vector.

Whether that is really an issue for any given application, depends on the application (e.g. how shortlived the crypto is and how bad decryption acter the fact is). But if you are asking that question it likely means you don't know enough knowledge to roll your own crypto unless you wanna be in a world of pain.

Just because PRNGs appear unpredictable to you does not mean they aren't.

If you really wanna go the route, at least add a salt, so something like

  Hash(application_secret_long_and_random + timestamp_nanosecond_precision)

Thanks! Macroexpanded:

There's Math.random(), and then there's Math.random() (2015) - https://news.ycombinator.com/item?id=38188421 - Nov 2023 (49 comments)

There's Math.random(), and then there's Math.random() - https://news.ycombinator.com/item?id=10751396 - Dec 2015 (106 comments)