Random number generation: It might be harder than you think to write code that rivals novice-level code written in Python.

About ChaCha20, in the table on the website, I was talking about the OpenBSD implementation, which is the only implementation of ChaCha20 as a PRNG that anyone is likely to have used.

Oh come on, this is not at all fair! Besides, Google has been shipping Chacha20 for at least a year now in Chrome. That is probably the most widely-used implementation out there.

As for security claims, I make it fairly clear on the predictability page of the website exactly what I’m talking about and not. I am absolutely not recommending it as a stream cipher for cryptography (given how new it is that’d be absurd!), but I am saying that even general purpose RNGs should have an eye to not being predictable.

I'm not sure I understand the distinction you are making between predictability and trivial predictability. In what situation would I find acceptable to use a generator that is predictable, but simply not trivially?

As for my speed claims, I’m not sure how you get the notion that there isn’t much difference between the Mersenne Twister and PCG (or other fast RNGs), the graphs make it clear that it’s more than twice as fast.

Yes, but consider that we are talking about differences in the order of 2 or 3 CPU cycles (per output word). This can easily go one way or the other with various microarchitectures, compiler optimizations, etc. This is rightly pointed out in the paper, and a best effort is made to make it fair. PCG may very well win, but talking about 2x at these scales can give the wrong idea, since any performance difference will look huge due to the CPU cycle granularity. MT will also have more variance due to the many memory accesses required during state updates.

Speaking of which, it would probably make more sense to talk about CPU cycles than nanoseconds in benchmarks, at this level (I was actually looking at the paper's Table 1, not the website). Cycle counts are both more informative and easier to verify than nanoseconds, in my view at least.

For what it's worth, I am also not at all a fan of the C++11 random API and algorithm choices. PCG is an improvement over the many crappy generators littering programming languages. These days, however, with stream ciphers being so fast I see no reason to use insecure generators without a very good justification. People will invariably use them to generate keys and the like, so it's better to play it safe.

/r/cpp Thread Parent