home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2878 < prev    next >
Encoding:
Text File  |  1992-08-12  |  5.1 KB  |  111 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!yale!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!knight
  3. From: knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
  4. Subject: more mcrypt discussion
  5. Message-ID: <1992Aug12.185029.13607@mintaka.lcs.mit.edu>
  6. Summary: more mcrypt discussion (isn't that was title is for?) 
  7. Keywords: mcrypt 
  8. Sender: news@mintaka.lcs.mit.edu
  9. Organization: It doesn't look like much, but its a system 
  10. Date: Wed, 12 Aug 1992 18:50:29 GMT
  11. Lines: 98
  12.  
  13. Mr. Ritter:
  14.  
  15.     Thank you for your reply, I greatly appreciate it (and thank you
  16. to the other people who have helped out!  I take back my previous
  17. comments.)  I've taken this information into consideration and I'm
  18. going to answer a few of questions and ask a few questions about
  19. some of your answers.
  20.  
  21. > If the scheme kept files at *exactly* the same size, I would agree.
  22. > But if the file size changes (increases) at all, then we cannot
  23. > (say) simply encipher disk sectors, and what really matters is
  24. > exactly *how much* the increase is.  Perhaps we should consider DES
  25. > to be equivalently "much more practical" since it also does not
  26. > expand files (except for blocking and size indication).
  27.  
  28.      The increase is the excess blocking.  I encrypt in exactly 
  29. 1024 byte (1K) blocks.  I created this method for telephone and disk
  30. based encryptions -- a "packet" style encryption method.
  31. The excess is never more than 1023 bytes and can be as little as 0.
  32. This all depends on (filelength % 1024) and so only that area is
  33. increased in size.  And DES has that problem as well, maybe not to
  34. the same degree, but due to computer file clusters, this block doesn't
  35. take up any additional space from the drive.   
  36.  
  37. > >No random numbers will be used anywhere in this encryption.
  38. >
  39. > Normally, random numbers are used as part of a cipher system
  40. > to *solve* serious problems.  A problem which comes to mind
  41. > in this system is whether the internal key-space is provably
  42. > uniformly distributed among the possible states.  If not, then
  43. > we need to assign individual probabilities to the possible
  44. > states in order to understand the overall strength, and this
  45. > can get very complex.
  46.  
  47. Okay, I can understand this perfectly.  I'll write up an explaination
  48. on how my encryption converts the password line to the 'template'.
  49.  
  50.  
  51. > *  Without specific algorithms to examine, key-space limitations
  52. >    cannot be understood, and this is really the heart of any
  53. >    cipher.
  54.  
  55. I'm assuming everyone knows what a simple shuffle does.  I've already
  56. included an example of my bit substitution.  I'll post the key
  57. generation method soon.
  58.  
  59. > *  Because of a lack of any statement otherwise, apparently the
  60. >    scheme always enciphers in the same way with the same User Key.
  61. >    If so, this is a serious weakness because it allows anagramming
  62. >    between different messages (and this is the classical method of
  63. >    breaking transposition ciphers).  In general, no cipher scheme
  64. >    should "ever" re-encipher the same data in the same way even
  65. >    with the same User Key.  (One way around this is to first encipher
  66. >    a "really random" Message Key, and use the plaintext Message Key
  67. >    as the internal key for ciphering the actual data.)
  68.  
  69. You'll have to explain this to me, because I'm wondering if my
  70. implementation doesn't completely by-pass this possibility.
  71. Yes, the 'keys' are the same.  They are also disposed and are not
  72. located anywhere within the file.  PASSWORD and PASSWORDPASSWORD 
  73. are not the same, due to the fact password length is included as
  74. part of the generation of the template (key) but only in manipulation
  75. and not in deducable mathmatical values (you'll see.) 
  76.  
  77. I've never seen DES encrypt a binary file before, I believe that is
  78. why you refer to it as "plaintext" cyphers.  I could be missing the
  79. point, but I'm not just encrypting data strings that match ASCII.
  80. Every attempt made to crack mcrypt will result in a file that will
  81. be produced as a result of the key.  To prove you have 'broken' the
  82. encryption you MUST create your own way of verifying -- which in
  83. itself is just a guess at the contents.  Even filelength is variable
  84. because failure to give the right key will cause the 'excess blockage'
  85. value to be altered.
  86.  
  87. The basic random influence is "lack of content knowledge" or human.
  88. If I had a file called "secrets.E" with a filesize of 8192 bytes
  89. it could be decoded into ascii, zip, arc, arj, tar, shar, pak, zoo,
  90. Z, z, or even be DES encrypted or encrypted twice with mcrypt.
  91. This could also be ROT-13 or something just as cheezy.
  92.  
  93. Even were there as few as a million permutations, how do you
  94. determine if its right?  This is a bad excuse, as I was trying
  95. to gain permutations to the point that technology won't catch
  96. up with this system any time during my lifetime.  I'm still
  97. confident there are more than DES.
  98.  
  99. Yes, I was attempting to create an encryption that would become
  100. I/O bound as the limit to its speed.  Most other systems become
  101. CPU bound (DES, great example.)  I/O is significantly slower than
  102. CPU and that causes problems repeatitively trying to guess it.
  103.  
  104. > ---
  105. > Terry Ritter    ritter@cactus.org
  106.  
  107. -- Eric Knight
  108.    knight@gnu.ai.mit.edu
  109.  
  110.  
  111.