home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / sci / crypt / 5103 < prev    next >
Encoding:
Internet Message Format  |  1992-11-20  |  2.0 KB
  1. Path: sparky!uunet!nntp1.radiomail.net!csl.sri.com!boucher
  2. From: boucher@csl.sri.com (Peter K. Boucher)
  3. Newsgroups: sci.crypt
  4. Subject: My encryption program.  Comments?
  5. Date: 20 Nov 1992 22:44:53 GMT
  6. Organization: Computer Science Lab, SRI International
  7. Lines: 43
  8. Distribution: world
  9. Message-ID: <1ejpp5INNdef@roche.csl.sri.com>
  10. NNTP-Posting-Host: affirmed.csl.sri.com
  11.  
  12.  
  13. I wrote a stream-cipher encryption program, and I was wondering if I
  14. could get some feedback on my algorithm (no pun intended).
  15.  
  16. 1) It generates a stream of pseudo-random numbers, based on a pass-phrase
  17.    typed by the user (between 13 and 1019 characters).  The first 
  18.    ~million bytes of pseudo-random numbers are generated when the program
  19.    starts up.  Call it "key_stream."
  20.  
  21. 2) A separate, single pseudo-random byte is also generated at the start.
  22.    It's value depends on generating the entire initial key_stream.  Call
  23.    it "zipper."
  24.  
  25. 3) the program executes a loop containing the following (pseudocode)
  26.    to encrypt a file:
  27.     inchar = getchar(infile)
  28.     outchar = inchar ^ key_stream[counter] ^ zipper  <-- "^" means xor
  29.     counter = counter + 1
  30.     zipper = outchar
  31.     putchar(outfile, outchar)
  32.  
  33. On a sparcstation, it goes through a 2 meg file a couple seconds (i.e.,
  34. not appreciably) slower than %cat file > file_copy.
  35.  
  36. The brute force attack would be to modify the code to only decrypt the
  37. first X bytes of the encrypted file (there's no way to generate less
  38. than the first ~million bytes of the key_stream, because the value of
  39. the zipper depends on generating all of them).  Then you'd have to run
  40. the modified version against a library of pass-phrases to see if any of
  41. them produce a recognizable X bytes of plaintext.  Of course, if the
  42. target knows what your value of X is, then X+1 bytes of garbage can be
  43. prepended to the plaintext before encryption, and you'll never
  44. recognize it.
  45.  
  46. What other attacks might work?
  47.  
  48. How can I analyze the key_stream to make sure that it's random enough
  49. (cryptographically strong)?
  50.  
  51. -- 
  52. Peter K. Boucher
  53. --
  54. RIPEM public key available upon request.
  55.