home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / sci / crypt / 4631 < prev    next >
Encoding:
Text File  |  1992-11-11  |  3.0 KB  |  83 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!swrinde!cs.utexas.edu!sun-barr!ames!news.hawaii.edu!wiliki.eng.hawaii.edu!newsham
  3. From: newsham@wiliki.eng.hawaii.edu (Timothy Newsham)
  4. Subject: is this bad?
  5. Message-ID: <1992Nov12.011804.12685@news.Hawaii.Edu>
  6. Sender: root@news.Hawaii.Edu (News Service)
  7. Nntp-Posting-Host: wiliki.eng.hawaii.edu
  8. Organization: University of Engineering, College of Engineering
  9. Date: Thu, 12 Nov 1992 01:18:04 GMT
  10. Lines: 71
  11.  
  12.  
  13. I got a number of replies to my query, thanks everyone.. however
  14.  
  15. ----
  16. From cme@ellisun.sw.stratus.com Tue Nov 10 20:50 HST 1992
  17. Subject: Re:  is this bad?
  18.  
  19. You haven't described it well enough.
  20.  
  21. For example, where does the  DES iteration get its key?
  22.  
  23.  
  24. I'd suggest you write a simple program to give your algorithm and
  25. post it that way.
  26. That's a lot clearer -- less likely to be ambiguous.
  27. ----
  28.  
  29. when few replies mentioned I should just use the CBC mode of DES
  30. it became apparent to myself that I hadn't stated my goals well
  31. enought either...
  32.  
  33.  
  34. goal:  an encryption scheme that gives me the strength of DES
  35. along with the ability to send single characters one at a time.
  36. Also it would be nice if the scheme lended itself well to
  37. sending 7-bit characters in only 7 bits.
  38.  
  39. my scheme:
  40. both ends agree upon a private key K 
  41. one side sends the other side an initial 8 bytes of random data
  42. to be used as the initial 'previous plaintext'.
  43.  
  44. to send bytes of the plaintext the sender encrypts
  45. the previous 8 bytes with key K and uses the resulting 8 bytes 
  46. 1 at a time to xor with the plaintext. After these 8 bytes
  47. of 'pad' are used up, 8 more bytes are generated from the
  48. previous plaintext.
  49.  
  50. example:
  51. previous bytes where 'hello th'
  52. which encrypt as  ('hello th')K = 'abcdefgh'
  53. now to send the next arriving byte 'e' i send  'a' xor 'e'
  54. when I get the next byte 'r' I send  'r' xor 'b' and so on.
  55. after sending the next 8 bytes 'ere how ' I encrypt them
  56. ('ere how ')K = 'blahblah'  and use those as pad.
  57.  
  58. at the other end,  the last 8 bytes of plaintext it had received
  59. is also 'hello th'.  The receiver also computes ('hello th')K
  60. and gets the same pad.  It uses the pad to xor the incomming
  61. stream to recover the new plaintext 'ere how '.  It can
  62. then compute ('ere how ')K and use those to decode the next
  63. 8 bytes.
  64.  
  65.  
  66. This scheme allows one to send signle characters 1 at a time
  67. instead of waiting for 8.  If this is being used in real
  68. time I can send 'e' right away without waiting for
  69. 'ere how ' to be available to me.  If DES is used in its
  70. normal mode of operation I would be required to either
  71. wait for 8 bytes of plaintext to be available or to time
  72. out every once in a while,  pad what I do have to fill
  73. out 8 bytes, and send the data.  The first is unacceptable
  74. for real time traffic and the second adds extra characters
  75. to the stream degrading performance and adding complexity.
  76. The extra characters are sent usually at times when nothing
  77. else is going to be sent (if stream isnt sharing space on
  78. a multiplexed link) so that isnt so much a problem.
  79.  
  80.  
  81.  
  82. I hope this is a little bit more clear than last time.
  83.