Michael Sierchio wrote: > David Schwartz wrote: > > >>> Deterministic is the antithesis of truly random. > > I think you're obliged to define what you mean by "truly random" -- > maybe even think about it before using such terms.
It's a well-understood term in the art. Understanding the distinction between truly random, pseudo-random, predictable, and so on is the price of admission to have a meaningful opinion on RNGs and PRNGs as used in cyrptography. > Most processes that generate "random" noise don't usually have > an nice, equiprobable, Poisson distribution. Of course. Not all random strings contain as much entropy as their length would make possible. > So what's "truly" > random? I don't think you know. Sure, I can tell you if "7" is random or not. But that doesn't mean I don't understand the term as it is used in this field. In fact, I do. http://random.org/analysis/ http://world.std.com/~cme/html/randomness.html > I'm not sure about your > understanding of deterministic, either. A deterministic process is one whose output is solely dependent on its input. That is, it follows a precise sequence of steps in a precise order such that it will always produce the same output from the same input. PRNGs are deterministic in this sense. For the same input, they will always produce the same output stream. If you assume an attacker knows their input and their algorithm, they cannot be used to provide cyptographically-secure random numbers. > Is the latched output of a free-running oscillator and a clock > "truly" random? Thermal noise? Radioactive decay? All of these thins are believed to contain at least some truly random output if constructed properly. Do you think I need to know more than everyone else about these esoteric issues which have no relevance to what I was saying? > The distinction you make, with ill-defined and poorly understood > terms, is specious. Among the mind-blowingly stupid things you've > said in this thread: In fact, it's the same distinction everyone else in this field makes. > So /dev/random tries to provide truly random numbers while > /dev/urandom tries to provide only cryptographically-secure > pseudo-random numbers This is, in fact, precisely correct. The man page says: When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. /dev/random should be suitable for uses that need very high quality randomness such as one-time pad or key generation. When the entropy pool is empty, reads from /dev/random will block until additional environmental noise is gathered. -and- A read from the /dev/urandom device will not block waiting for more entropy. As a result, if there is not sufficient entropy in the entropy pool, the returned values are theoretically vulnerable to a cryptographic attack on the algorithms used by the driver. Knowledge of how to do this is not available in the current non-classified liter- ature, but it is theoretically possible that such an attack may exist. If this is a concern in your application, use /dev/random instead. If you think this is different from what I said, you're going to have to explain why you think that. Because you are completely wrong. > It's as assured by the implementation as RSA assures that > its operations are irreversible. > Well, these statements are false. I leave it up to you to decide > whether such utterances are, on their face, stupid. I anxiously await your argument. In fact, the statement above that begins "Knowledge of how to do this" is making precisely the same point I am. If you don't know anything about an entire field, the least you can do is keep your mouth shut. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
