All real crypto keys come from PRNGs (if they don't, you have bigger problems). If your PRNG sucks, you're in trouble. You aren't as secure as AES; you're as secure as your RNG.
Bernstein used a similar visualization to show diffusion in his stream cipher over multiple rounds:
Well ... the last time I had to generate real crypto keys for an application I used a 300 US$ (in 1996) TRNG pod that used thermal noise to provide truly random data.
We can be rather sure that TRNGs are used to make one time pads for the intelligence community ... although strangely enough the Venona decrypts are based on the Soviets having reused pages of random numbers, probably due to the high demand that developed after they were invaded by Nazi Germany.
But your point about the need for a high quality (and well seeded) PNRG is well taken, far too many cryposystem failures have been due to that.
As I tell people, don't worry about the cipher, you will not do better than the experts, but make sure your whole system is sound.
And speaking of seeds, in the brave new world of cloud computing we've got to be careful about where we get our entropy.
Then, due respect, but the last time you had to generate real crypto keys for an application you did so in a very unrepresentative setting. Virtually all real-world crypto ends up depending on a CSPRNG.
I'm sure PRNGs have been used to make "one time pads"[1]. And as you know, those aren't actually one time pads. They're stream ciphers based on PRNGs, and are as secure as the underlying PRNG --- meaning, probably not secure at all. Calling them OTP's perpetuates a misconception about the applicability of OTPs to real crypto.
People have been saying "don't worry about the cipher, think about the whole system" for two decades now, but that message has been attenuated down to "use AES, don't try to design your own block cipher". Frankly? At this point? I think you'd do better if you started by actually designing a simple Fiestel cipher. At least then you'd be assured some basic understanding of what these algorithms actually do.
If you want to think scary thoughts about crypto and cloud computing, remember that I can now spend a couple bucks to get access to a machine that has nanosecond timing resolution to your secure app by nature of it being a single switched gigE hop away.
Sorry about tit-for-tatting your reply, which was interesting, but I think I had at least 2 worthwhile things to add to the discussion there. Thanks for giving me the vector to do that.
[1] (By way of backstory for the rest of you: one time pads are "theoretically unbreakable" cryptosystems where you and your counterparty somehow securely exchange blocks of truly random data, and encrypt/decrypt by combining that random key matter with data on a 1:1 basis. They have no relevance to real-world crypto, since they depend on you having a way to reliably and securely exchange and retain key material that is as long as the messages you're actually sending).
You overstate the situation with one time pads: they eliminate the decryption issue by shifting it entirely to key distribution.
As for "real-world crypto", they've certainly been used in the 20th century and the continued existence of number stations as mentioned on HN in the last couple of days suggests that such simple systems might still be in use. It's hard to get more simple than a booklet of TRNG data printed on flash paper and a shortwave receiver.
Instead of annoying everyone by arguing definitions for the rest of the day, let's just stipulate that we're talking about "crypto done by computers using products that you can actually buy and conceivably deploy in a commercial setting".
Unless you have a physically secure channel to distribute keys (in which case, why bother with OTPs), the fact that OTPs move the security model entirely to "key distribution" is an academic point. Any online key distribution system you'd come up with for your OTP is (a) going to become the fulcrum of your entire system, and (b) by nature of feeding an OTP, going to permit a far more restricted set of designs than any key distribution system for a "conventional" protocol.
The reality is, OTPs are entirely unsuitable for commercial information security. That's a strong claim, but not a slippery one, and I'm willing to back it up.
The arguments around OTPs are surprisingly isomorphic to the arguments around Javascript crypto.
I agree with your strong claim, with the single exception of "TRNG data that you can physically hide (i.e. in a PCIe card) may be a useful source of keys or entropy". Which was the sort of thing I was using it for in 1996.
As for your last point, I'd personally substitute "intuitively obvious" for "surprisingly", but I will admit I've been playing this game on and off for a long time
Perhaps for the same reason I run NoScript ( 1/2 :-) ?
OPTs obviously devolve to the key distribution problem.
The environment of client side Javascript is obviously to me a superset of the key distribution problem. After all, you start out by distributing your code to the (insert your favorite derogatives here) client.
Simson Garfinkel likes to refer to the whole https game as something like transferring a valuable from a cardboard box in an alley via an armored car to a park bench. I'd end with the end of a Matt Groening Love is Hell quote: "At night, the ice weasels come."
The only conclusion you can draw from Reddit is that his pictures would be less interesting if you use mt_rand() instead of rand(). mt_rand() is still insecure.
Since published research on RNGs seems to severely lag research on block ciphers and even hash functions, it seems like a really bad idea to build anything that needs to be safe on an RNG that was never designed to be secure.
I certainly wasn't trying to debate the value of mt_rand or it's implementation of the Mersenne Twister. I was simply trying to point out this is an extremely old issue, and that the problem specified in the article (a visible problem with rand()) is removed by using mt_rand(). Also, the issue only occurs due to problems with the PRNG on Windows specifically and was not present on other operating systems. The use of php's rand() or mt_rand() for applications that require security seems to be outside the scope of the article as it was presented since the author didn't necessarily understand the topic as can be seen by his proposed solutions.
You managed to point out how extremely old this issue was in a manner that implied that mt_rand() was safe for use for security. Since this is an extremely, extremely common problem in PHP code, your comment did more harm than good.
My complaint had more to do with the fact that the article contains no date information than the fact it was resubmitted. Since it contains no date information someone that is seeing it for the first time might think this was a brand new issue and no one was aware of the problem.
Bernstein used a similar visualization to show diffusion in his stream cipher over multiple rounds:
http://cr.yp.to/snuffle/diffusion.html