home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2924 < prev    next >
Encoding:
Internet Message Format  |  1992-08-17  |  4.7 KB
  1. Path: sparky!uunet!bonnie.concordia.ca!clyde.concordia.ca!altitude!elevia!alain
  2. From: alain@elevia.uniforum.qc.ca (W.A.Simon)
  3. Newsgroups: sci.crypt
  4. Subject: well braid
  5. Message-ID: <13989@elevia.uniforum.qc.ca>
  6. Date: 17 Aug 92 22:38:30 GMT
  7. Lines: 107
  8.  
  9. In years past, I proposed and explained (many times and in various
  10. manners) a new way to confuse the ennemy, whomever this might be.
  11.  
  12. A number of weaknesses were found in my proposal, all of them relating
  13. -- in my opinion -- to the telling rather than to the tale.
  14.  
  15. I still have not addressed them adequately, but I do not propose to
  16. sneak by.  My purpose today is to ask questions and try casting a new
  17. light on the subject.
  18.  
  19. My own renewed interest is the result of an avalanche of e-mail (3
  20. messages!!!) asking for details, following a recent reference to my
  21. work in sci.crypt.
  22.  
  23.  
  24. Quick recap
  25.  
  26. The proposed system works by multiplexing (braiding) two or more bit
  27. streams.  Depending on the value of key bits, the next bit of output
  28. is taken from one or the other input.
  29.  
  30. One or more of these streams is/are made of relevant text, the balance
  31. being random noise, rude noises and other confusing non messages.
  32.  
  33. One or more (this too is key dependant) of the noise streams can be used
  34. as fresh material to be expanded/added into a future key.  This resolves
  35. the tricky problem of key distribution without extra cost.
  36.  
  37. Once the braid has been constructed, the level of security (confusion)
  38. is such that it is not required (but not forbidden) to encrypt the
  39. resulting stream.  As the number of braided streams increases, so does
  40. the level of security.
  41.  
  42. A braided stream could be used as input to the manufacture of yet
  43. another braid, in order to increase the level of security some more.
  44.  
  45. The larger the difference between the length of the plaintext and that
  46. of the braid, the more an opponent is likely to find a "known plaintext".
  47. This is called the "wishfull plaintext" defense.
  48.  
  49. In anticipation of being forced to divulge the plaintext, one of the
  50. streams (or more) could be designated as a decoy and an ad hoc key
  51. manufactured to produce any particular stream as the only intelligible
  52. result.
  53.  
  54. A braided stream could easily pass for a random stream (assuming a
  55. well randomized key).
  56.  
  57.  
  58. Tiny regret
  59.  
  60. So far, no implementation has been produced.  I did not do anything
  61. about it because I'd rather play with the concept than write code.
  62. I have not exhausted the exploration of this concept, and I found
  63. new (related) concepts to play with...
  64.  
  65. A number of people have expressed interest in writing a working
  66. application, but I am yet to hear of a single project that reached
  67. completion.
  68.  
  69.  
  70. Big questions
  71.  
  72. Let's assume for a moment that we have a good random source for a key.
  73. Now, we take two text files and we braid them (witout injection of
  74. random material).  We know the two files are plain English text.
  75. Using the tools of the cryptographic trade, can we recover the two
  76. files?
  77.  
  78. What clues do we have?  To begin, the high order bit of each plaintext
  79. byte is always 0; how far can we reason on this knowledge alone?  What
  80. help is the knowledge of letter frequencies in rebuilding individual
  81. bytes?  How many possible ways can 2 bytes be combined at the bit level?
  82. How many valid byte pairs can we rebuild from 16 bits? What are the odds
  83. for each successive bit to belong to one byte rather than to the other?
  84. How can the problem be formally stated?
  85.  
  86. Now, we make the second text random instead of English.  How is the
  87. complexity of the problem affected? How are the odds changed?  And
  88. if we make the number of streams more than two?  If we make all streams
  89. 8 bit non English? Is the problem too much or is it just more of the
  90. same with higher horse power requirements?
  91.  
  92. A really kinky one now: we have two known plaintext streams.  We have
  93. their braid (still no injection of random material).  How many possible
  94. keys could have produced the same braid from these two plaintexts?  If
  95. we only know one plaintext in advance, how many possible guesses would
  96. be suitable for the second plaintext?  How many of them plausible?
  97.  
  98. Finally, the hard one: we don't know the number of streams in the braid.
  99. We don't know the key.  We suspect there is injection of random noise (in
  100. other words, not all streams are meaningfull).  We think we know the
  101. plaintext.  How many streams was the plaintext divided into? How can we
  102. be certain the plaintext we know about was really the one sent out? How
  103. do we know that it was the only meaningfull one in the braid? How many
  104. streams were there?  Which ones will be used to rejuvenate the key?
  105.  
  106.  
  107. Good random source?
  108.  
  109. This is a whole story by itself...  to be continued, I am sure.
  110.  
  111.  
  112.  
  113. --
  114.  The Vacuum Cleaner Man (reality sucks)
  115.  God made me a chauvinist, my woman made me clean the house
  116.