home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / sci / crypt / 3725 < prev    next >
Encoding:
Internet Message Format  |  1992-10-12  |  3.2 KB
  1. Path: sparky!uunet!snorkelwacker.mit.edu!thunder.mcrcim.mcgill.edu!sobeco!ozrout!elevia!alain
  2. From: alain@elevia.uniforum.qc.ca (W.A.Simon)
  3. Newsgroups: sci.crypt
  4. Subject: Re: Pseudo-one-time pads
  5. Message-ID: <14020@elevia.uniforum.qc.ca>
  6. References: <1992Oct2.172914.2263@vixvax.mgi.com> <1992Oct3.015908.12242@ulysses.att.com> <1992Oct5.221733.27777@netcom.com>
  7. Date: 12 Oct 92 09:14:46 EDT
  8. Lines: 68
  9.  
  10. In <1992Oct5.221733.27777@netcom.com>
  11. rlglende@netcom.com (Robert Lewis Glendenning)
  12. writes:
  13. > There are two issues here: 1) The academic consideration of RNGs with
  14. > "truely" random distributions and 2) The consideration of being able to
  15. > predict the random number series.
  16.  
  17.     For the sake of accuracy:
  18.  
  19.     (1) is it statistically random?
  20.     (2) is it predictable?
  21.  
  22.     if (1) is not true, the chances for (2) becoming
  23.     true increase.  This is the academic argument.
  24.  
  25.     The pragmatic argument says it is possible to
  26.     generate a stream for which (2) is true, without
  27.     consideration for the truth of (1).  But the fact
  28.     is that if (2) is true, you can bet that (1) is
  29.     likewise.  It won't be an accident.
  30.  
  31. > All of the academic consideration of RNGs I have seen focus on 1). 2) is
  32. > necessary for using them in an encryption system. I have made my RNGs
  33. > pretty unpredictable by running 32 different Additive Congruential Method
  34. > RNGs, and only selecting one bit of each for each 32-bit number. I do so
  35. > by randomly (another RNG) selecting the particular bit from each. Of course,
  36. > this is computationally extremely expensive.
  37.  
  38.     You have 32 PRNG using different parameters (but same algorithm).
  39.     You pick 1 bit from each, but in RANDOM order.  How random?  Is
  40.     it another PRNG?
  41.  
  42.     You realize that if each PRNG is not cryptographically secure in
  43.     its own right, the 32 are not any more secure, unless you have
  44.     a "true" random source to pick your PRNG sequences.  In which
  45.     case you don't need the 32 PRNGs.
  46.  
  47. > I believe that the OTP using itis pretty safe. However, safety can be improved
  48. > by compressing the oriignal file and then distributing it randomly through
  49. > a random number file.
  50. > [ ... ]
  51.  
  52.     PRNGs can be usefull as key generators, if they are used
  53.     to pick material from a non random source, but nevertheless
  54.     unknown to the opposition.  Take one PRNG and use the result
  55.     to index into a string of sufficient length (say, some book
  56.     on CD).  As long as you don't divulge the source of your raw
  57.     material (and change it often) you are in clover.  But: how do
  58.     you distribute the key?  Do you phone your covert correspondant
  59.     and tell him to go buy the CD?  Aside from the annoying security
  60.     considerations, can you be sure the two of you will get the exact
  61.     same text (editions vary from country to country)?
  62.  
  63.     But why bother with PRNG's of you have access to long files
  64.     you can share with your correspondants.  The files themselves
  65.     are good enough as a source of key material.
  66.  
  67.     Suppose you have enough raw material to make two files.  For each
  68.     character of each file generate a parity bit.  If the two bits
  69.     are different use the byte from the first file, else use the
  70.     byte from the second file.  Advance to next byte of each file.
  71.     Or you could simply use the parity bits as your OTP key.
  72.     These are just two samples of the many ways...
  73.  
  74.  
  75.  
  76. --
  77.  Alain
  78.