home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / crypt / 6471 < prev    next >
Encoding:
Internet Message Format  |  1993-01-06  |  3.6 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!cs.utexas.edu!rutgers!concert!samba!usenet
  2. From: John.Carver@launchpad.unc.edu (John Carver)
  3. Newsgroups: sci.crypt
  4. Subject: how secure is this?
  5. Message-ID: <1993Jan7.043830.5273@samba.oit.unc.edu>
  6. Date: 7 Jan 93 04:38:30 GMT
  7. Sender: usenet@samba.oit.unc.edu
  8. Organization: University of North Carolina Extended Bulletin Board Service
  9. Lines: 69
  10. Nntp-Posting-Host: lambada.oit.unc.edu
  11.  
  12. I have, for personal use only (so don't ask for source :-) invented a
  13. small encryption utility.  I have no (zero, zippo, none) experience
  14. assessing the security of a cryptosystem, so I'm wondering if someone
  15. knowledgable in this area might give me some inkling of the degree of
  16. security of this system.  Mostly this is acedemic curiosity only - I'm
  17. just wondering whether what I made is any good.  (Aside from the fact
  18. that it isn't a public key system - ignore those issues, if you might -
  19. I'm just interested in security).
  20.  
  21. Here's how it works:
  22.  
  23.   1) An arbitrary length key is transformed into a 128 bit key.  The
  24.      initial arbitrary length key is purely for the convenience of the
  25.      user.
  26.  
  27.   2) This 128 bit key is used for two things:
  28.      A) it is used as the "seed" for pseudo-random number generator.
  29.      B) it is used to modify the algorithm used by the above random
  30.         number generator by changing key parameters used when generating
  31.         the pseudo-random sequence.
  32.  
  33.   3) Step 2) is run multiple times using different parameters to produce
  34.      multiple pseudo-random sequences (all from the same key, but all
  35.      different).
  36.  
  37.   4) The sequences from 3) are used to encrypt the plaintext.  Some of
  38.      the sequences perform character translation in-place.  Others
  39.      perform character relocation within blocks of a length defined
  40.      pseudo-randomly by the initial key (but within given bounds).  The
  41.      multiple sequences from 3) perform the above two operations
  42.      multiple times, interleaved.  (Ie, 1st a character translation
  43.      pass, then a relocation pass, etc.)  The number of passes is,
  44.      again, determined pseudo-randomly from the initial key subject to
  45.      given bounds.
  46.  
  47. How secure is this?  Since I know nothing about the relative security of
  48. various algorithms, I just tried to come up with something that would
  49. hopelessly scramble the plaintext, in the hopes that this would somehow
  50. be secure.  How did I do?  (probably worse than I suspected, right? :-)
  51.  
  52. Side notes:
  53.  
  54.   1. Each of the pseudo-random sequences generated from the initial key
  55.      has been shown to be non-repeating for at least 10^7 digits.  The
  56.      actual length is probably much greater.  In any case, this is far
  57.      larger than the expected message length.
  58.  
  59.   2. Since the initial key is 128 bits, I doubt that a brute-force
  60.      attack is very practical for your typical PC user.  The algorithm,
  61.      when coded in C, can encrypt 45 Kb per second on an Amiga 4000
  62.      (appoximately a 22 MIP machine).  It is not all that fast,
  63.      obviously, so I'm assuming its safe from brute-force methods on
  64.      anything short of a Connection Machine 5, and maybe even there :-)
  65.  
  66.   3. I have verified that 1 bit changes in the key produce entirely
  67.      different crypted data.
  68.  
  69.   4. I have verified that the crypted data appears random from the
  70.      viewpoint of character frequences.  Ie, sending all "a"'s as
  71.      plaintext yields binary data using all 256 character codes roughly
  72.      equally. 
  73.  
  74. John
  75.  
  76. --
  77.    The opinions expressed are not necessarily those of the University of
  78.      North Carolina at Chapel Hill, the Campus Office for Information
  79.         Technology, or the Experimental Bulletin Board Service.
  80.            internet:  laUNChpad.unc.edu or 152.2.22.80
  81.