On Fri, 05 Oct 2007 16:54:32 GMT, bealoid
wrote:
>>>Because "random" is tricky to define.
>> You will find that it has been defined pretty precisely.
>"Is 2 random?"
Like statistics, such a determination (in the context under
discussion) cannot be made from a single sample.
>> There are
>> programs that will measure just how close a set of numbers is to a
>> random set.
>All of which say that the set "appears to be random" - not that it is
>random.
Well yes - that is the nature of randomness. There is always a
*chance* that an undetectable pattern exitsts. The point is that so
long as any pattern remains undetected, there is no way to distinguish
it from a set where no pattern exists.
>>> Neither of the sets are really random.
>> Nonsense! A-D conversion of noise is an accepted method of
>> *generating* random numbers.
>Wait, are we still talking about crypto randomness, or just some other
>wishy-washy randomness? Because there's a few flaws with A-D conversion
>of noise. The software tests you mention show hardware noise generators
>can be pretty poor
>< / >
Um .. AFAICS the biggest problem was in the software that extracted
the numbers in one case, which was assuming ASCII data and inserted a
carriage return character before every occurance of a linefeed
character! Obviously an *extremely* inept programmer. The other case
was due to faulty hardware.
>So, if you want to generate going to generate a small amount of random
>data you're okay with A D conversion of noise, but to generate a
>significant amount you're going to end up with bias and correleation.
Only if you make some rather basic mistakes!
>Both of which makes the data "differently random" to the other random
>stuff.
It will not. I do this stuff for a living, and have studied it
extensively.
>>> Mashing two almost-random sets together doesn't mean that you end
>>>up with one big set, you end up with two mixed sets.
>>
>> Also nonsense. We are replacing one random number set with another
>> random number set. It is impossible to determine whether the
>> replacement has taken place or not by looking at only one set. It is
>> not merely "very difficult" to tell, it is 100% *impossible* to tell.
>> There is no pattern whatsoever in the data that was replaced, and
>> there is no pattern whatsoever in the replacement data.
>
>But there is a pattern - as the link above shows - even in hardware
>generators.
The link showed one (unforgivable) programming boo-boo, and one
hardware generator that was faulty. If a sound card becomes similarly
faulty, the output file would not have valid sound data (or at least
very distorted sound).
In any case, the fault described resulted in a bias in the 0's and
1's, which should be almost equal in a large enough sample. If you do
not know (and cannot find out) whether the device that created the
file you are dealing with should have such a bias or not, it does not
assist in being able to determine the presence of hidden data.
The hardware generators described must be either old devices or units
built by someone who doesn't know what they are doing. All generators
that I have seen has the noise fed through a toggle (divide by two)
which ensures that there cannot possibly be a bias between 0's and 1's
no matter how assymetric the noise signal is.
--
Cynic