🚀 go-pugleaf

In article <1993Jan8.173701.8858@ncar.ucar.edu> prz@sage.cgd.ucar.edu (Philip Zimmermann) writes:
>>    - the  sequence  of  random numbers has strong prevalences on
>>bytes (up to 0.05 ...  0.1 on material of 10000 byte) and  strong
>>correlation dependence between contiguous bytes;
>
>Really?  How so?  What does "strong prevalences" mean?  Is he talking
>about the internal random number source in random.c, used for making
>RSA keys?  Or is he talking about the output of the IDEA cipher?  In
>either case, evidence should be presented that allows others to
>reproduce his results.  The random.c code for getting randomness from
>keyboard latency has been tested pretty well, and it uses MD5 to
>enhance the raw randomness from the keyboard timings.  It looks
>pretty good to me.  Does the IDEA cipher running in CFB mode output
>text that appears nonrandom?  This is disturbing, if true.  Biham and
>Shamir have thus far not succeeded in finding weaknesses in the IDEA
>cipher.  Perhaps Dr. Sidelnikov has found one.  I'd like to see some
>evidence of this claim.  

It is not my intent to add fuel to any fire, but this seems like a good
springboard to voice a potential concern I have had with the Unix port of
pgp.  Pgp seeds certain random number vectors by asking the user to type
some characters at the terminal and then measuring the times between
keystrokes. I know Phil gave some thought to this for pgp1.0, and it
probably works well in a DOS environment.  However, some flavors of Unix do
not have the ability to measure time to the same granularity as DOS, and,
combined with the multiprocessing environment of Unix, the times gathered
may not be representative of the typist's true signature.  I have not looked
at the code, but, empirically, I have gotten quite a few instances of '?'
when performing this ritual, which I believe means the number was thrown
out because it was too small.

Has anyone indeed paid any consideration to the randomness of the numbers
so generated under Unix?  It would be comforting to know that someone has
looked into this, and even more comforting to know they concluded that
this is, indeed, not a problem.
-- 
Rob Stampfli  rob@colnet.cmhnet.org      The neat thing about standards:
614-864-9377  HAM RADIO: kd8wk@n8jyv.oh  There are so many to choose from.