7 ms·
No platform in 2015 should even have a poor PRNG. It's pretty sad really. rand() in C, rand() in PHP, Math.random() in JS. Any use case where you want a poor
by admax88q 11y ago
No platform in 2015 should even have a poor PRNG. It's pretty sad really.
rand() in C,
rand() in PHP,
Math.random() in JS.
Any use case where you want a poor random number generator is a niche use case and you can write your own. We should be secure by default.
- baudehlo 11y agoIf you want a random entry from an array, Math.random is fine. Anyone who doesn't know that prng's are broken for things like uuids shouldn't be in charge.
- seanwilson 11y agoThere's something to be said about having sensible defaults that prevent common mistakes though. Everyone makes mistakes.
- baudehlo 11y agoTrue. But every language has gone through this issue. Node is particularly vulnerable to weak prng seeding due to relying on forking to support multiple processes. Am I that old and grumpy to expect people to be aware of the history here?
- seanwilson 11y agoI think the size of this thread as well as the existence of blog posts like this means it's a mistake that's always going to be repeated. There's way too many programming gotchas to expect people to keep track of them all. Language support to avoid classes of mistakes is a great idea to me e.g. such as having a good random algorithm by default and a UUID library.
- johncolanduoni 11y ago> Anyone who doesn't know that prng's are broken for things like uuids shouldn't be in charge. Depends on how you're using them. If you only care about collisions, and you're not worried about an attacker trying to manipulate your system, then using a PRNG whose output is well-distributed (read: not necessarily a language's random function) is fine. The problem is most language's default PRNGs are complete crap :( edit: grammar
- kalleboo 11y agoThe bug report that prompted V8 to fix their Math.random was someone doing A/B testing on their site by checking Math.random()>0.5, and the V8 PRNG was so bad that it would give a consistent 2-3% error, which would make any results useless. Seems like V8's Math.random was only fine for extremely trivial cases (Google doodle Pacman I guess). Meanwhile Webkit has been using a CSPRNG and nobody seems to be complaining.
- mike_hearn 11y agoYeah - the thing I was thinking throughout the article was .... this is all interesting, but isn't it an obvious consequence of using a runtime designed for more quickly loading the Gmail UI on the server side? I went and checked the docs for the Java Math.random() function and it clearly specifies the algorithm and doesn't have the same issue. V8 is a great piece of work but it was never intended for anything beyond speeding up web pages. Why are people using node.js on the server side at all, when there are more industrial strength runtimes with better performance available?
- mmalone 11y agoIf you want to do something as trivial as an unbiased Fisher-Yates shuffle of an array, however, Math.random() is broken. And Math.random() doesn't have to be broken for things like UUIDs. Python and Ruby both have PRNGs that are suitable for such things. We fucked up by not vetting the algorithm, that's definitely the primary lesson here. Mea culpa. I'm sure you would have done things differently, but V8 is a modern system and I don't think assuming a modern PRNG was completely unreasonable while quickly getting to MVP at a new startup.
- notzorbo2 11y agoYou seem to be getting a lot of flack from people with 20-20 hindsight. For what it's worth, I have made the exact same assumptions you have when generating internal unique IDs in a distributed system purely for tracking purposes. The only difference was that mine was in Python and I got lucky that its random implementation uses a mersenne twister.
- PhantomGremlin 11y agoWe fucked up by not vetting the algorithm, that's definitely the primary lesson here. Mea culpa. Bingo. Exactly. I heavily criticized you in another post for 1) your initial choice of substandard algorithm and 2) your rationalizations (e.g. Google's "good reputation"). But that is ancient history. Here you're admitting that you fucked up, which IMO you didn't admit previously. Also, kudos for your article which kicked off this entire discussion. In that article you showed that you carefully analyzed what was happening, how you went wrong, and how you could improve. Even more important, you did this all publicly, both your article and your responses here on HN. Everyone learns from this. I commend you for your openness.
- Dylan16807 11y agoWell Google fucked up too, in a way that affects many more people. They used a broken form of an obsolete random number generator with a 2^30 cycle. There are faster and simpler generators that perform overwhelmingly better on statistical tests.
- yoklov 11y agoI'd definitely argue that needing a CSRNG is more niche than needing a fast RNG.
- tedunangst 11y agoPerpetuates fallacy that CSRNG is not fast.
- johncolanduoni 11y agoOn many platforms it's several orders of magnitude slower than a fast, dead simple PRNG with very good distributional properties, like xorshift1024* [1]. [1]: http://xorshift.di.unimi.it http://xorshift.di.unimi.it
- tedunangst 11y agoLet's return to the top. How many random bytes do you need per second? Rounded to the nearest billion, of course.
- pcwalton 11y agoIf your product is in a competitive environment and is being compared against others in benchmarks of random number generation, the answer is "as many as you can possibly generate". This scenario corresponds to JavaScript engines of major Web browsers.
- tedunangst 11y agoIn other words, bullshit breeds bullshit.
- pcwalton 11y agoI can't blame V8 engineers for not wanting to regress SunSpider. Sad or not—and, let me tell you, nobody who works on browsers likes this state of affairs when it comes to that benchmark—doing well on the popular benchmarks has to be an engineering goal in the environment browsers find themselves in.