Slashdot Mirror
Fixing JavaScript's Broken Random Number Generator (hackaday.com)
szczys writes: It is surprising to learn how broken the JavaScript Random Number Generator has been for the past six years. The problem is compounded by the fact that Node.js uses the same broken Math.random() module. Learning about why this is broken is interesting, but perhaps even more interesting is how the bad code got there in the first place. It seems that a forum thread from way back in 1999 shared two versions of the code. If you read to the end of the thread you got the working version, if you didn't make it that far (perhaps the case with JavaScript devs) you got the bad version of the code whose fix is just now being rolled out.
https://xkcd.com/221/
1% APY, No fees, Online Bank https://captl1.co/2uIErYq Don't let your $$$ sit in a no-interest acct.
Is there anything about Javascript that isn't shitty and broken? Can we please just take this language behind the barn, shoot it and move on with our lives?
What? Does the ECMA spec dictate the exact implementation of the RNG? If not, then it's not JavaScript that's broken, but the implementation(s) in question. Calling it "JavaScript's Broken RNG" is nonsense unless the language spec mandated or mandates a broken RNG.
A successful API design takes a mixture of software design and pedagogy.
What did you expect from some random coder?
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
Because JavaScript doesn't specify the RNG implementation details, and V8 is the only engine mentioned ass affected in the article ...
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
That said, even JvN understood the usefulness of pseudo random numbers for things like Monte Carlo simulations. I believe he favored Linear Congurential Generators (Knuth liked 69069 as a multiplicand on a 32-bit word).
The article doesn't claim it's new information. The article is about the fact that Google has finally fixed it and the backstory behind the broken code.
Well if you don't like RNG you should try WHM, BML or THF.
So now that we know it's Kasper Lund who broke this within the V8 engine, is someone going to do a code audit of all checkins he's done within the Dart SDK to make sure he hasn't broken anything related to PRNGs and cryptography?
JavaScript was not designed by any regular use of that word. JavaScript happened.
We should carve out an exception for the sincerely held religious beliefs to serve or not serve any particular random number for the generator.
sed -e 's/Chuck Norris/Rajnikant/g' joke > fact
That's why JS is untyped, it adds much needed randomness.
Since seed values are important, why not just use the comments in slashdot - some of them are REALLY random.
Or use the latest presidential campaign statements - can't get much more random than that (for some definitions of random).
"Transparent" is a shit show that trades on every stereotype going. A man in drag is NOT a transsexual.
This is fixing Google's random number generator; Firefox, Safari and MS Edge (if not old IE versions) have never had this issue, it is specific to Google's JS implementation.
I've seen some pretty bad "random number" generators in my time. In one case, it was implemented by a pointer that would walk through the processes memory space and use whatever it found as-is. And another where the coder clearly thought that if you multiply something by enough made up crap and take the remainder, you get randomness. An understanding of random numbers in computing is not something the classrooms ever cover as far as I can tell.
See this table for support: http://caniuse.com/#feat=getra...
It's great that they're finally improving Math.random(), but node.js should've had crypto.getRandomValues() from the start.
Given there is no way to seed math.random assumptions about collisions are meritless and storage of random identifiers in databases serves no useful purpose other than causing needless index fragmentation.
In short TFA while having a point about quality of a specific implementation of math.random() is bitching about things that could still be failures even if math.random() represented an ideal PRNG.
Also hardware random number generators are what you get for free when you sleep through your 101 class on noise margins. Invoking the normal exotic bullshit about computation and radioactively decay is completely unnecessary. Good old thermal noise is what most hardware random number generators use and is as nondeterministic as any "quantum" outcome.
Seems like this should just affect Chrome / Chromium and anything derived from those, as it's an implementation issue in the V8 JavaScript interpreter. (V8 is the name for the engine in Chrome.)
That is, it's not a JavaScript / ECMAScript bug in the standard (as implied by the headline), but rather a bug in one company's implementation.
Compare/contrast with the comically bad PRNG enshrined in the C standard itself:
static unsigned long int next = 1; // RAND_MAX assumed to be 32767
int rand(void)
{
next = next * 1103515245 + 12345;
return (unsigned int)(next/65536) % 32768;
}
Thankfully, though, this is just an example, and not required by the standard. But, many simple C compilers use that implementation. It's got plenty of problems, such as always alternating between even and odd values. If the last value was odd, the next value is even....
Program Intellivision!
Knuth covers this definitively in Volume 2 of "The Art of Computer Programming". I think I first read it in 1979 so it certainly used to be covered in teaching, maybe that's all been lost in the later generations. Now get off my lawn.
The new 128-bit generator is shown as this piece of code, using a pair of 64-bit state variables:
uint64_t state0 = 1;
uint64_t state1 = 2;
uint64_t xorshift128plus() {
uint64_t s1 = state0;
uint64_t s0 = state1;
state0 = s0;
s1 ^= s1 > 17;
s1 ^= s0;
s1 ^= s0 >> 26;
state1 = s1;
}
The absolute minimum latency of that code is 8 clock cycles, assuming that the two initial loads happen at the same time and that the writeback of s1 to state1 is overlapped with the return, i.e. free.
It seems like an obvious optimization to notice that s0 could be updated in parallel with the two initial s1 updates, i.e.
s1 ^= s0;
s1 ^= s0 >> 26;
can instead be written as
s0 ^= s0 >> 26; // These two clock cycles can be overlapped with the previous s1 updates!
s1 ^= s0;
since we don't care about the s0 value after this point and XOR operations are commutative (it is of course possible that the compiler is smart enough to do the same optimization, but I doubt it):
This is two clock cycles faster than the original code.
Terje
"almost all programming can be viewed as an exercise in caching"
I thought it was axiomatic that the inbuilt default PRNG was good for writing scissors/paper/stone when doing programming 101 but not for anything more serious.
In any language.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
The more of an application you do server-side, in a language of your choosing, the less you have to depend on browser JavaScript (and other browser issues). But, it takes experience to do that well. One cannot think in "desktop mode" anymore, and toss much of their desktop UI design experience. It's bummer, but it's what the Web Stack forces on us if we want to avoid JavaScript and client-versioning headaches.
Table-ized A.I.