Earlier quoted context omitted.
A quantum process is a random process, but isn't it still an open philosophical question as to whether the "random process" we observe is truly random, or is instead governed by deterministic hidden state?
No, all theories of (local) hidden variables have been experimentally ruled out. https://en.wikipedia.org/wiki/Bell%27s_theorem > Bell's theorem states that any physical theory that incorporates local realism cannot reproduce all the predictions of quantum mechanical theory. Because numerous experiments agree with the predictions of quantum mechanical theory, and show differences between correlations that could not b…
On Melissa O’Neill’s PCG random number generator
71–80 of 90 posts
Re: On Melissa O’Neill’s PCG random number generator
#72I once tried to develop my own fast random number generate using nothing but bitwise operations. On the theory they were the fastest/simplest. I had a program generate thousands of random combinations of bitwise functions. And then used statistical tests to see which ones produced the most "random" seeming behavior. It worked as far as I can tell. But I don't trust the statistical tests. Who is to say there isn't a v…
Re: On Melissa O’Neill’s PCG random number generator
#73Earlier quoted context omitted.
>linear congruential random number generator (well known, but not very good) Relevant quotes from the paper: "But if you began reading the section with the belief that “linear congruential generators are bad” (a fairly widely-held belief amongst people who know a little about random number generation), you may have been surprised by how well they performed. We’ve seen that they are fast, fairly space efficient, and a…
Two-to-the-forty-seven nanoseconds is a little over thirty-nine hours. (Let's see HN mangle that !)
Re: On Melissa O’Neill’s PCG random number generator
#74Earlier quoted context omitted.
I've often been frustrated trying to put more than one asterisk (not italic tag) in an HN comment. Serious question, what happened to WYSIWYG? The Web has supported it for like 20 years, why have we standardized on clunky in-line markup for rich text entry, pretty much everywhere?
WYSIWYG is kinda crap on mobile. A checkbox saying "Don't format" would be nice, though.
Re: On Melissa O’Neill’s PCG random number generator
#75Earlier quoted context omitted.
>linear congruential random number generator (well known, but not very good) Relevant quotes from the paper: "But if you began reading the section with the belief that “linear congruential generators are bad” (a fairly widely-held belief amongst people who know a little about random number generation), you may have been surprised by how well they performed. We’ve seen that they are fast, fairly space efficient, and a…
> 247 nanoseconds is less than two days Yes, yes it is. For those just as confused as I was, replace all instances of 247 with 2 47
That doesn't appear to help ;-)
Re: On Melissa O’Neill’s PCG random number generator
#76Physicist here. Off-topic > And it is not even entirely clear what “really random” would mean. It is not clear that we live in a randomized universe… At the quantum level it really is clear that we live in a really random universe. What's the meaning of really random? The outcome of a quantum process. On-topic. Yeah, you have to know your audience. As OP mentions, just because the paper wasn't published doesn't preve…
Re: On Melissa O’Neill’s PCG random number generator
#77Earlier quoted context omitted.
If you stripped out all the (weird, random) cryptographic stuff from this paper, it would read pretty much the same and make pretty much the same points, which tells me: it's not a cryptographic paper.
That's a fair point; it was mostly the presence of the random crypto that annoyed me :)
Also, I notice that lots of people seem to think her paper was too long, but they also claim that it doesn't say enough about their favorite topic. That seems to be happening with you.
Direct quote from O'Neill's comment here https://www.johndcook.com/blog/2017/07/07/testing-the-pcg-ra...
John, in your post, you said that PCG has “excellent statistical and cryptographic properties”. I’ve learn it best never to say “cryptographic security” or “cryptographic properties” when trying to place something on a spectrum of prediction difficulty. Too many misunderstandings. Saying “prediction difficulty” still causes some crossed wires, but it’s about as good as we can go.
Dan & Dmitriy, just to be 100% clear, I HAVE NEVER RECOMMENDED PCG FOR CRYPTOGRAPHY. I do however, care about prediction difficulty, and I don’t like trivially predictable generators. Because my viewpoint is often misunderstood, I have some more blog posts in the pipeline about these issues, but the key thing is that general-purpose PRNGs get used for almost anything, from using the low-order bit to toss a coin, to supporting randomized algorithms. If someone can predict your generator, they can mount an algorithmic complexity attack on your randomized algorithm, tanking its performance. If predicting the generator is more costly than the algorithmic complexity attack itself, people will try their attacks on easier targets. But if the generator spends to much time being trying hard to be unpredictable, we also tank our performance, thus we have to try to strike a balance in a different place than we do for traditional cryptographic applications. We already live in a world where hash table implementations in scripting languages need to be hardened because of algorithmic complexity attacks; this is the next logical step.
All that said, there are members of the pcg family (not pcg32 and especially not pcg32_fast!) that I personally think would be really challenging to predict. I also find it frustrating that people don’t compare like with like. If you want to compare the prediction difficulty of PCG against a cryptographically secure PRNG, you need to compare a PCG variant at least broadly similar in size. Say, for example, we wanted to contrast PCG against the ChaCha PRNG from Orson Peters (perhaps with four rounds rather than the full 20), that PRNG is 104 bytes in size, so it’s fairest to compare it to pcg64_c8, which is 80 bytes, or pcg64_c16, which is 144 bytes.
Regarding prediction difficulty, I’m very well aware of Bruce Schneier’s law, “Anyone, from the most clueless amateur to the best cryptographer, can create an algorithm that he himself can’t break. It’s not even hard. What is hard is creating an algorithm that no one else can break, even after years of analysis. And the only way to prove that is to subject the algorithm to years of analysis by the best cryptographers around.”, and his subsequent elaboration “Anyone can invent a security system that he himself cannot break. I’ve said this so often that Cory Doctorow has named it “Schneier’s Law”: When someone hands you a security system and says, “I believe this is secure,” the first thing you have to ask is, “Who the hell are you?” Show me what you’ve broken to demonstrate that your assertion of the system’s security means something.” Thus my personal thoughts on how difficult it is mean NOTHING in a cryptography context. I also can’t expect cryptographers to spend their time on my education, but if someone out does know a simple and efficient algorithm that can reliably break pcg64_c8, I really would love to see how. (Also, hey Bruce, gender-neutral language, it’s a thing.)
I can do at least one thing that adds a tiny tiny tiny bit of credibility in the eyes of folks like Bruce Schneier , I can show other PRNGs I have broken that might have seemed hard to predict to a casual observer. Mostly that won’t actually help though, because a cryptographer would say “Ha! That’s toddler level stuff!” and a mathematician might say “I can’t understand why you care about prediction at all”. Sometimes I feel there should be more people trying to occupy the middle ground. Meh.
But, let’s be clear, DO NOT USE PCG FOR CRYPTOGRAPHY. DO NOT USE PCG FOR CRYPTOGRAPHY. DO NOT USE PCG FOR CRYPTOGRAPHY. Clear?
Re: On Melissa O’Neill’s PCG random number generator
#78A few notes: The author writes "Meanwhile, at least one influential researcher (whose work I respect) had harsh words publicly for her result", and then quotes some of these words: Note that (smartly enough) the PCG author avoids carefully to compare with xorshift128+ or xorshift1024*. However, the author fails to note that said "influential researcher", Sebastiano Vigna, is the author of xorshift128+ and related PRN…
O'Neill has instructions on how to test with PractRand and with TestU01 on her blog (http://www.pcg-random.org/blog/). I had a go with TestU01 on Vigna's generators, and when you test the low 32 bits reversed (for 64-bit PRNGs, you have to test the high 32, the low 32, both forwards and reversed), I found that all Vigna's generators fail.
Given the PractRand results it makes sense, I guess, but I had read that Vigna's generators were supposed to pass TestU01.
Does anyone else wants to have a go at testing so I can know if I screwed up somehow?
Re: On Melissa O’Neill’s PCG random number generator
#79- PCG is not crypto, everybody should understand that. It's for simulation and rendering.
- PCG mainly replaces Mersenne Twister which is in c++11. The Twister has a LOT more state and is a LOT slower for less randomness.
- In rendering and simulation speed really matters, and PCG excels there.
- Xorshift is another algorithm in the same class. I would really like to see an objective comparison. In my cursory engineering look PCG seemed better.
- Fast PRNG is almost a new field again: It's not crypto, but immensely useful. How did the Twister get into C++11 while it is so much worse than PCG or Xorshift? Nobody cared!
- Maybe PCG should have been a paper at SigGraph.
- For the style of the paper, I think one contribution is rethinking PRNG outside crypto. That deserves and requires a lot of exposition.
Re: On Melissa O’Neill’s PCG random number generator
#80Here's the site for the random number generator.[1] It's basically a simple linear congruential random number generator (well known, but not very good) fed into a mixer. The mixer is new. Most of the analysis is about the LCG or the final output. The suggested mixer is just output = rotate64(uint64_t(state ^ (state >> 64)), state >> 122); That's simple, and the insight in this paper is that something that simple help…
It's a weird paper. It's quite long and takes an eternity to reach this simple point. It's also littered with "security concerns" which are confusing at best and misleading at worst; in reality, none of the generators it discusses are suitable for "sensitive applications", even in the corner-case scenario it discusses of needing permutations of all the b-bit integers, a problem we already have cryptographic tools to…
Based on things she's said on her site and in comments on John D. Cook's blog, it's all about algorithmic complexity attacks on randomized algorithms.
In other words, if you're doing quicksort on external input with a random pivot, and someone knows the PRNG state, they can make a pathological input that'll trigger quadratic behavior.
I don't know how likely this is to happen, but I know there were similar attacks on hash tables a few years ago.