home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / crypt / 4674 < prev    next >
Encoding:
Internet Message Format  |  1992-11-12  |  5.3 KB

  1. Path: sparky!uunet!ogicse!uwm.edu!zaphod.mps.ohio-state.edu!sample.eng.ohio-state.edu!blanc!butzerd
  2. From: butzerd@blanc.eng.ohio-state.edu (Dane C. Butzer)
  3. Newsgroups: sci.crypt
  4. Subject: Your post about pseudo one time pad...
  5. Message-ID: <1992Nov12.171127.2162@ee.eng.ohio-state.edu>
  6. Date: 12 Nov 92 17:11:27 GMT
  7. Article-I.D.: ee.1992Nov12.171127.2162
  8. Sender: news@ee.eng.ohio-state.edu
  9. Organization: The Ohio State University Dept of Electrical Engineering
  10. Lines: 105
  11.  
  12.  
  13. I was going to reply via e-mail, but I can't seem to reach you (and I
  14. forget how normal mail works ;-).  Anyways, maybe some of the other
  15. non-experts will have some other comments...
  16.  
  17. Also, I did not mean for the original post to come off as an attack on the
  18. FAQ.  I think the FAQ is very informative (esp. to a newcomer).  I would be
  19. willing to help w/ it in any way possible (although I'm obviously not an
  20. expert - more of a serious hobbyist :-)
  21.  
  22. Now, on to it:
  23.  
  24. In article <1992Nov11.193848.10946@rchland.ibm.com> lwloen@vnet.ibm.com writes:
  25. >In article <1992Nov11.173642.29608@ee.eng.ohio-state.edu> Dane C. Butzer
  26. >writes:
  27. >
  28.  
  29. [My stuff describing DES as a pseudo one time pad omitted]
  30.  
  31. >
  32. >>This is pseudo one time pad that I don't think would be "easy" to break.
  33. >
  34. >I agree, in principle, with your last statement.  But, it isn't what I had
  35. >in mind when writing.  And, it does not contradict what I said.
  36.  
  37. Wasn't trying to contradict you :-)
  38.  
  39. >
  40. > [Stuff about DES != typcal "random number generator" and clarification of
  41. >  the type of PRNG you had in mind omitted]
  42. >
  43. >Indeed, I personally avoid the
  44. >word "random" in the sense you call "cryptographic randomness"; I tend to
  45. >call it "unpredictable" as contrasted with "random" and mean "algorithmically
  46. >unpredictable" as opposed to "algorithmically random" since we are dealing 
  47. >with pseudo-randomness in virtually every case where these ideas apply anyway.
  48. >
  49.  
  50. Good idea.  I'll do that from now on.  How about trying on a new acronym,
  51. too: URNG for Unpredicatble Random Number Generator, to distinguish RNGs
  52. that are designed for cryptography from the typical PRNGs?
  53.  
  54. >As the old "Ax+C" pseudo-random number generator shows, there is a clear
  55. >distinction between satisfying statistical tests for randomness and avoiding
  56. >a cryptanalyst's hunger for a predictable keystream.  Unfortunately, while I
  57. >do see this fine point much discussed, it is not done in a standardized way
  58. >and is certainly hard to convey to the uninitiated.
  59.  
  60. Another good point.  Hopefully, via your FAQ, we may get some standardization
  61. of terms, atleast within the newsgroup.  Or is that too much to hope for?
  62.  
  63. >
  64. > [stuff about how DES in electronic codebook mode gives you a nice random
  65. > number stream... for 8 bytes :-) and how DES in CFM would work OK for POTP]
  66. >
  67. >So, such methods, if done right, are exactly as safe or as vulnerable as
  68. >DES itself.  Done wrong (as I just gave an example above), it is not
  69. >as good, of course.  But, you seem to understand this already.  (Perhaps you
  70. >were wondering if I do :-) ? ).
  71. >
  72.  
  73. Actually, I was just making sure I wasn't missing something.  From the way
  74. pseudo one time pads are usually frowned upon, I thought I was.  However, I
  75. hadn't found anything in the literature about that, and I'd seen several
  76. proofs of the absolute security of a true one time pad, so I was getting a
  77. bit worried that I'd overlooked something obvious :-(
  78.  
  79. >The problem is, of course, random number generators designed to satisfy
  80. >statistical randomness may well not satisfy at all the need for being
  81. >unpredictable in a cryptographic situation; most are very poor at this, in
  82. >fact, not having been designed with the problem in mind.  Most novices do
  83. >not understand the distinction between "randomness" as in passing Chi Square
  84. >and "unpredictable" as in frustrating analysis.  So, they grab any old
  85. >random number generator out of Knuth or something and usually grab wrong.
  86. >
  87. > [stuff omitted]
  88. >
  89. >Can I/How do I concisely clean it up with out hopelessly confusing the novice?
  90. >I thought about the DES example,but decided to leave it out on grounds of not 
  91. >the right audience for the added information.  I don't want to have them read
  92. >a section that intends to tell them that Ax + C "random" number generators
  93. >are worthless and have them come to the opposite conclusion, even if I clean
  94. >it all up, at length, elsewhere.
  95. >
  96. >Is there something simple I can say that will fix this, but won't introduce 
  97. >the "Ax+c is OK" problem, which is far worse, in my judgement, than leaving 
  98. >it as is?
  99.  
  100. I'm not sure.  You may want to include a section on randomness, and note
  101. that there is a definite difference between statistical randomness, and
  102. unpredictable in the sense of frustrating analysis.  I think that this is a
  103. sufficiently basic point to include in the FAQ.  Then you could note
  104. that the typical novice's PRNG might very well satisfy statistical
  105. randomness, but probably won't satisfy "unpredicability".  Next you could
  106. show a statistically good PRNG (as I recall, Ax+c and other linear
  107. recurrence equations are actually pretty good statistically, right?), and
  108. show why it wouldn't work as an unpredictable random number generator
  109. (UNRG? :-) However, this might just confuse some of them too much anyways,
  110. and lead to the "Ax+c is OK problem".  It may just be better to let people
  111. that aren't sure about this issue post, like I did.  Anyways, thanks again
  112. for the clarification...
  113.  
  114.  
  115.  
  116. Dane Butzer
  117.