home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2906 < prev    next >
Encoding:
Internet Message Format  |  1992-08-15  |  2.7 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ogicse!mintaka.lcs.mit.edu!hal.gnu.ai.mit.edu!knight
  2. From: knight@hal.gnu.ai.mit.edu (Knight of Tossing and Turning)
  3. Newsgroups: sci.crypt
  4. Subject: Growth of mcrypt due to packets
  5. Summary: Some more clarifications
  6. Keywords: mcrypt
  7. Message-ID: <1992Aug15.162947.688@mintaka.lcs.mit.edu>
  8. Date: 15 Aug 92 16:29:47 GMT
  9. Article-I.D.: mintaka.1992Aug15.162947.688
  10. Sender: news@mintaka.lcs.mit.edu
  11. Organization: MIT Laboratory for Computer Science
  12. Lines: 50
  13.  
  14.  
  15. Okay, there has been some debate about "how" my encryption causes the
  16. file to grow.  I'm sorry this took so long for me to post, I've been
  17. spending more of my time writing this program and showing relatives
  18. around my home town of Pueblo (send for your free government catalog)
  19. since they are up from Texas.
  20.  
  21. To show how this works, lets take a file 1025 bytes long.
  22.  
  23. Since the encryption deals with 1024 byte chunks, the first "block"
  24. of 1024 bytes is encrypted so that it only needs 1024 bytes to store
  25. all the information..  Basically, same size or one-to-one.
  26.  
  27. The next block consists of only a single character.  Of course, this
  28. is really bad since this character (or small string of characters
  29. if it is more) could (and probably will) give away methods to solve 
  30. the entire system if mcrypt kept this data the same size prior to
  31. encryption as it would be after the encryption.
  32.  
  33. To solve for this problem, I opted to just fill the rest of the
  34. data (unused) with garbage, and use the file length to tell the
  35. decryption routine to stop.  Nothing fancy there -- it can be 
  36. drawn straight out of a random number generator.  All the garbage
  37. will be intermixed with plaintext and thereby keeps it protected.
  38.  
  39. The filelength itself will be placed in a final packet at the end
  40. of the grid (haven't gotten around to placing this yet, I've only
  41. used an integer for testing.)  I figured this number would be
  42. best to encrypt as well because knowing the true file length could
  43. also be considered a 'weakness' of the system.
  44.  
  45. I'm not worried about the 1-2K of extra data, at least the value 
  46. of growth is a reasonable X+2, and not X1.5 or X^2 or something
  47. that will explode in the long run.  It isn't even a matter of
  48. principle. 
  49.  
  50. On the "help from others" note:
  51.  
  52. I've been running benchmarks on mcrypt today, and it runs at 
  53. about 10K/sec on my 386-33 running Linux.  I'll compile it
  54. for single user mode soon.  If anyone has some benches for DES
  55. I'd be interested in knowing how fast it is on your CPU.
  56.  
  57. Finally, I've grabbed several books on cryptanalysis and hopefully
  58. I'll be able to discuss my idea a little closer to "normal".
  59. Thank you people who have suggested books to read.
  60.  
  61. Source code will soon be available for people to kick around.
  62.  
  63. --- Eric Knight
  64.