> No it isn't. You -want- a RNG but you can't have one. Nobody > -wants- a PRNG, they -settle- for it. I think there is some confusion here - if you are using a PRNG as a stream cypher, the last thing in the world you want is for it to be truely random - you need to sync up two prngs in order to decrypt the message, and randomness would defeat that (I can see a case where you introduce a little randomness and use some redundant method to strip it out before encryption, but that's only a second layer of obscurity of little value if the mainstream crypto is borken.
> What one wants is a bit sequence which is > -random-. if you want random numbers, get a rng - a prng is never going to be a rng, and everyone knows it. given you are using a prng in any case, does it matter if the prng sequence being used happens to be a sequence of pi, or any other fixed sequence? > > any subset of the digits of pi is as close to RNG output as you would > > need to satisfy any entropy tests - unless you *knew* you had derived it > > from pi you couldn't distinguish it from a true random string of the same > > size. > Satisfying an -entropy test- is -not- equivalent to -being- a RNG. It only > says that within a particular error margin you're -close enogh-. indeed so. but if someone has said a prng is truely a rng, I must have missed it. > Really? The offset into the sequence is a fixed width and the result is > alaways a single character. Where do you add a bit? what makes you think the offset is a fixed width? pi is of infinite length (or so I am told) so any offset is also at least potentially of infinite size. speed and physical construction constraints limit that, but not enough to fit your claims of it being easily defeatable. > > the single-digit-of-pi formula is too slow to form a good stream cypher, but > > is otherwise ok; > Maybe for you, I sure as hell wouldn't use it either as a key or as a > seed into a known hashing/whiting algorithm. its probably a better (if much slower) stream cypher than most currently in use; I can't think of any that have larger than a 256 internal state, and that implies a 2^256 step cycle at best; for pi to be worse, it would have to have less than 2^256 digits. > Let me ask you a more pointy question. Are you selecting some offset and > then taking the sequence of digits from pi, or are you selecting the > digits out of order? In either of these cases it isn't the sequence of pi > that is providing the randomness (which is apparently the claim) but > rather the selection process; which is both undescribed at this point > -and- simply moves the argument from one area to another - this -proving- > nothing. no, you are using a subset of a pseudo-random stream of infinite length; there is little benefit in selecting digits at random, if you are relying on the pseudorandomness of the stream itself. I am at a loss to see what you are driving at, so am forced to assume we are considering radically different cases.
