0

If you have the seeds for Math.random() using mwc1616, are the random numbers generated in the same order every time / are they repeating? Basically wondering if, given a seed, can I predict past outputs of Math.random()?

(Given say 8 Math.random() outputs from the past, if I find the seed they were generated with, could I potentially figure out what the 9th Math.random output would have been had the pervious 8 been generated in succession?)

I've been trying to find the seed for a set of Math.random outputs using this tool: https://github.com/XMPPwocky/nodebeefcl, it doesn't work when I add more than 2 outputs though.

1

That is a pseudorandom number generator.

So, yes, that's what all PRNGs do:

Given a specific seed, always produce the same sequence of only seemingly random numbers. That happens by initializing the internal state from the seed, and then, every time a number is generated, updating the internal state and outputting a number.

I've only superficially looked at MWC1616:

The two generators have the form
x(n)=a*x(n-1)+carry mod 2^16 and
y(n)=b*y(n-1)+carry mod 2^16,
in this case a and b are choosen as 18000 and 30903

Considering that it's mostly a linear algorithm, I'd say it should perform especially bad in terms of being able to conceal the internal state from reverse engineering.

I'd expect that algorithm to be bad in terms of quality, too. This can even hypothetically only achieve a sequence length of 2³² (so, easy to simply brute force the next number by going through all 4 billion in minutes at most values on a modern PC) albeit having 64 bits of state, but I'd be surprised if the sequence length was not actually shorter.

All in all, a very bad algorithm. What ancient library / programming language brought you this? If possible, consider using a different random generator (from different authors, tbh; "roll your own PRNG" is about as clever as "roll your own crypto") or different platform.

  • It's from V8, a common JavaScript engine, though they've apparently replaced it since then with xorshift128+, which is no more cryptographically secure (at least as far as anyone claims) but a significantly better PRNG. – Nic Hartley Jul 15 at 22:16
  • Here's an explanation of the problem I'm trying to solve if you want to take a look (pastebin.com/RfaCYCbY), but this answers my question either way. – Marshall Jul 16 at 3:51
  • 2
    @NicHartley I. uh… um. Yeah. Yay. JavaScript. One of the best software ecosystems in existence. – Marcus Müller Jul 16 at 7:43
  • @Marshall Python wouldn't be my prime choice for this, due to language handling overhead, but C/C++ would. Take the pseudo-random generator in C/C++, use an arbitrary seed, and generate 2³² consecutive pseudorandom numbers, always checking whether the ones you know are there consecutively. Should really only take minutes. – Marcus Müller Jul 16 at 7:45
  • 1
    No idea. If I had to speculate, I'd say they picked something that looked -- visually -- like it was random enough. This didn't cause major issues because Math.random() was only ever meant to be a quick-and-dirty RNG. At some point, people started realizing that quick RNG didn't have to mean bad RNG, so they asked V8 to change it to something that's both quick and good, and... they did. (Well, that's not totally speculation, but it arises from things like talking to some of the people who work on V8, which isn't exactly citeable or reliable, so take it as speculation) – Nic Hartley Jul 16 at 14:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.