3 ms·

> So what makes this particular PRNG so weirdly sticky? Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and pro

> So what makes this particular PRNG so weirdly sticky? Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.

stouset 2y ago
It is dramatically harder to implement than most modern PRNGs. The PCG and xoroshiro+ families are like four or five lines of code. You could memorize them if you wanted to. Mersenne Twister is anywhere from 50-250 lines and I doubt anyone could reproduce it accurately without consulting the spec or a reference implementation or both.
- cookiengineer 2y ago
  Reproducibility does not mean implementability. What I meant with reproducibility is reproducibility of state, meaning that the seed produces the same result on both the frontend and backend side which doesn't mean that it is easy to do across different programming languages. > 50-250 lines Usually you try out a library or existing package first before you start to implement anything. That's how you develop stuff outside the C++ world :) dismissal intended. I think that MT19937 has a good balance between being easy to implement across various programming languages and type systems while also not necessarily being cryptographically secure. It's somewhere in the sweet spot of "good enough" for most use cases while also being a seed based randomizer. I also would not assume that frontend developer jobs come with mandatory cryptography knowledge criteria, which implies that there must be an available implementation across a lot of programming language ecosystems to get the same traction.
  - stouset 2y ago
    > Reproducibility does not mean implementability. You literally said it was “Easy to implement in pretty much all scripting and programming languages.” Reproducibility from a seed is a basic feature of essentially every non-cryptographic PRNG. It’s so fundamental to the problem domain it’s hard to even call it a “feature”. > Think of e.g. an online casino where every client can potentially cheat The solution to this is a server-side CSPRNG, not hoping your client generates predictably random numbers. If no party can trust any other, there are other solutions, none of which involve synchronizing non-cryptographic PRNGs. > I think that MT19937 has a good balance between being easy to implement across various programming languages and type systems while also not necessarily being cryptographically secure. It isn’t, and this simply isn’t a reasonable or informed thought. It is strictly and inarguably more complicated by a factor of ten than other PRNGs which are also faster, use less memory, and generate more uniformly random output. MT has zero advantages over the alternatives. I don’t say this lightly. There is no “balance” it strikes. It is worse along all axes. If you need a CSPRNG, use a CSPRNG. If you don’t, use something other than MT. Please just let MT die.
    - cookiengineer 2y ago
      Maybe you should start implementing other PRNGs then across various package management systems and programming languages to promote your cause? If you keep ignoring 90% of my opinion then I don't wanna discuss this with you anymore either. I never said MT is superior, it's what you implied.
      - stouset 2y ago
        Better PRNGs are widespread and available in literally every developer ecosystem. This isn’t the ‘90s. If PCG isn’t available for yours, it is trivial to reimplement. typedef struct { uint64_t state; uint64_t inc; } pcg32_random_t; uint32_t pcg32_random_r(pcg32_random_t* rng) { uint64_t oldstate = rng->state; // Advance internal state rng->state = oldstate \* 6364136223846793005ULL + (rng->inc|1); // Calculate output function (XSH RR), uses old state for max ILP uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u; uint32_t rot = oldstate >> 59u; return (xorshifted >> rot) | (xorshifted << ((-rot) & 31)); } That’s it. That’s the whole thing.
        cookiengineer 2y ago
        You are aware that you don't need to mansplain the implementation to me, right? My argument, from the beginning, was about maintainability from a company's perspective. Also you do realize I am not a user of MT, right?
        stouset 2y ago
        > My argument, from the beginning, was about maintainability from a company's perspective. Better mansplaining than gaslighting I suppose. Your argument, from the beginning, was (quoted in full): “Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.” None of your actual original argument, nor what you’re now claiming it was, nor the ones inbetween hold water. It’s reproducible like every non-CS PRNG. It’s not simple, or simpler than alternatives. It doesn’t strike a “balance” between simplicity and being cryptographic (which is frankly a really weird thing to say; being cryptographic isn’t a spectrum). It’s not CS, and so it competes against the modern alternatives which are strictly simpler. I mean I’m genuinely sorry that that you’re misinformed here, but that’s on you to reconcile. What’s the point in dying on this hill? > You are aware that you don't need to mansplain the implementation to me, right? If we’re being blunt and rude, it seems pretty obvious you did need this. > Also you do realize I am not a user of MT, right? In what way is this relevant?

> So what makes this particular PRNG so weirdly sticky? Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.

stouset 2y ago

It is dramatically harder to implement than most modern PRNGs. The PCG and xoroshiro+ families are like four or five lines of code. You could memorize them if you wanted to. Mersenne Twister is anywhere from 50-250 lines and I doubt anyone could reproduce it accurately without consulting the spec or a reference implementation or both.

cookiengineer 2y ago
Reproducibility does not mean implementability. What I meant with reproducibility is reproducibility of state, meaning that the seed produces the same result on both the frontend and backend side which doesn't mean that it is easy to do across different programming languages. > 50-250 lines Usually you try out a library or existing package first before you start to implement anything. That's how you develop stuff outside the C++ world :) dismissal intended. I think that MT19937 has a good balance between being easy to implement across various programming languages and type systems while also not necessarily being cryptographically secure. It's somewhere in the sweet spot of "good enough" for most use cases while also being a seed based randomizer. I also would not assume that frontend developer jobs come with mandatory cryptography knowledge criteria, which implies that there must be an available implementation across a lot of programming language ecosystems to get the same traction.
- stouset 2y ago
  > Reproducibility does not mean implementability. You literally said it was “Easy to implement in pretty much all scripting and programming languages.” Reproducibility from a seed is a basic feature of essentially every non-cryptographic PRNG. It’s so fundamental to the problem domain it’s hard to even call it a “feature”. > Think of e.g. an online casino where every client can potentially cheat The solution to this is a server-side CSPRNG, not hoping your client generates predictably random numbers. If no party can trust any other, there are other solutions, none of which involve synchronizing non-cryptographic PRNGs. > I think that MT19937 has a good balance between being easy to implement across various programming languages and type systems while also not necessarily being cryptographically secure. It isn’t, and this simply isn’t a reasonable or informed thought. It is strictly and inarguably more complicated by a factor of ten than other PRNGs which are also faster, use less memory, and generate more uniformly random output. MT has zero advantages over the alternatives. I don’t say this lightly. There is no “balance” it strikes. It is worse along all axes. If you need a CSPRNG, use a CSPRNG. If you don’t, use something other than MT. Please just let MT die.
  - cookiengineer 2y ago
    Maybe you should start implementing other PRNGs then across various package management systems and programming languages to promote your cause? If you keep ignoring 90% of my opinion then I don't wanna discuss this with you anymore either. I never said MT is superior, it's what you implied.
    - stouset 2y ago
      Better PRNGs are widespread and available in literally every developer ecosystem. This isn’t the ‘90s. If PCG isn’t available for yours, it is trivial to reimplement. typedef struct { uint64_t state; uint64_t inc; } pcg32_random_t; uint32_t pcg32_random_r(pcg32_random_t* rng) { uint64_t oldstate = rng->state; // Advance internal state rng->state = oldstate \* 6364136223846793005ULL + (rng->inc|1); // Calculate output function (XSH RR), uses old state for max ILP uint32_t xorshifted = ((oldstate >> 18u) ^ oldstate) >> 27u; uint32_t rot = oldstate >> 59u; return (xorshifted >> rot) | (xorshifted << ((-rot) & 31)); } That’s it. That’s the whole thing.
      - cookiengineer 2y ago
        You are aware that you don't need to mansplain the implementation to me, right? My argument, from the beginning, was about maintainability from a company's perspective. Also you do realize I am not a user of MT, right?
        stouset 2y ago
        > My argument, from the beginning, was about maintainability from a company's perspective. Better mansplaining than gaslighting I suppose. Your argument, from the beginning, was (quoted in full): “Reproducibility, on both client and server side. Easy to implement in pretty much all scripting and programming languages.” None of your actual original argument, nor what you’re now claiming it was, nor the ones inbetween hold water. It’s reproducible like every non-CS PRNG. It’s not simple, or simpler than alternatives. It doesn’t strike a “balance” between simplicity and being cryptographic (which is frankly a really weird thing to say; being cryptographic isn’t a spectrum). It’s not CS, and so it competes against the modern alternatives which are strictly simpler. I mean I’m genuinely sorry that that you’re misinformed here, but that’s on you to reconcile. What’s the point in dying on this hill? > You are aware that you don't need to mansplain the implementation to me, right? If we’re being blunt and rude, it seems pretty obvious you did need this. > Also you do realize I am not a user of MT, right? In what way is this relevant?