3 ms·

> Reproducibility does not mean implementability. You literally said it was “Easy to implement in pretty much all scripting and programming languages.” Reprod

> 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?
      - cookiengineer 2y ago
        Seeing your comment has been edited (again) at least 10 times the last 15 minutes, changing your argument, structure and content a lot that you want to criticize...the only thing I have left for you is this: If you learn to argue in echo chambers, you won't grow on a personal level. That's not how the real world works, and not in any job profession. Nobody in their right mind will say "you won that argument" if the opponent posts the implementation code as an argument that is supposed to win over the "lack of maintainability" argument before that. If you don't understand why there are package managers in the first place, then maybe you should ask someone _why_ they are so successful? I hope you learn to love the embedded development world, because you, right now, seem to be very unhappy in it. Otherwise you wouldn't be so enraged over a very simple argument like this one. I wish you the best. Maybe at some point in the future you will learn to differ critique on a subject from critique on a personal level. This was never a personal attack, and I thought I made that very clear. If you interpreted this as a personal attack, then I guess I am sorry? I won't change my previous comment because I think that is unfair behavior. The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. There is no point in "dying on this hill". Opinions change over time, there is never a right or wrong, ever, which will persist. _Everything_ is a tradeoff. If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. Implementations change, bugs are found, problems are discovered and fixed, knowledge changes. Just look at the PIKE/SIKE fiasco the last years. The only thing that persists is the constant maintenance burden. And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored.

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?
    - cookiengineer 2y ago
      Seeing your comment has been edited (again) at least 10 times the last 15 minutes, changing your argument, structure and content a lot that you want to criticize...the only thing I have left for you is this: If you learn to argue in echo chambers, you won't grow on a personal level. That's not how the real world works, and not in any job profession. Nobody in their right mind will say "you won that argument" if the opponent posts the implementation code as an argument that is supposed to win over the "lack of maintainability" argument before that. If you don't understand why there are package managers in the first place, then maybe you should ask someone _why_ they are so successful? I hope you learn to love the embedded development world, because you, right now, seem to be very unhappy in it. Otherwise you wouldn't be so enraged over a very simple argument like this one. I wish you the best. Maybe at some point in the future you will learn to differ critique on a subject from critique on a personal level. This was never a personal attack, and I thought I made that very clear. If you interpreted this as a personal attack, then I guess I am sorry? I won't change my previous comment because I think that is unfair behavior. The argument MT vs PRNG XYZ will never be won with implementation code as "proof that it is really better". I am not sure you understand that. There is no point in "dying on this hill". Opinions change over time, there is never a right or wrong, ever, which will persist. _Everything_ is a tradeoff. If you still think that, you haven't been coding long enough to see how much worse your own code was when you were younger. Implementations change, bugs are found, problems are discovered and fixed, knowledge changes. Just look at the PIKE/SIKE fiasco the last years. The only thing that persists is the constant maintenance burden. And I don't want to have to maintain a randomizer, because it's the most unnecessary thing to maintain with the most collateral damage if it's ignored.