home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / crypt / 6696 < prev    next >
Encoding:
Text File  |  1993-01-12  |  3.7 KB  |  102 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!cs.utexas.edu!milano!cactus.org!ritter
  3. From: ritter@cactus.org (Terry Ritter)
  4. Subject: A Modest Network Cipher
  5. Message-ID: <1993Jan12.093041.19342@cactus.org>
  6. Organization: Capital Area Central Texas UNIX Society, Austin, Tx
  7. Date: Tue, 12 Jan 1993 09:30:41 GMT
  8. Lines: 92
  9.  
  10.  
  11.  A Modest Network Cipher with Interesting Properties
  12.  
  13.  
  14.  The Problem
  15.  
  16.  Consider a need to software-encipher arbitrary-length data packets
  17.  within an existing network *without* adding *any* additional data
  18.  to the packets.
  19.  
  20.  
  21.  Approaches
  22.  
  23.  In this application, a block cipher is considered too slow, and
  24.  would require data buffering and frequent short-block padding.
  25.  
  26.  Instead consider a stream cipher consisting of two modules: a
  27.  "confusion" source, and a data/confusion "combiner."  A stream
  28.  cipher can be fast, and will eliminate buffering and padding.
  29.  
  30.  
  31.  The Stab-in-the-Back
  32.  
  33.  In this network, at the bottom level, there is not enough
  34.  information (or perhaps it takes too long) to identify individual
  35.  connections or data streams.  Each packet must, therefore, be
  36.  enciphered independently.  (This is a customer decision.)  Recall
  37.  also that there is no room for a message key at this level; thus
  38.  the same confusion sequence will be used for each packet.  (Ugh!)
  39.  
  40.  In a conventional stream cipher design, with an exclusive-OR
  41.  combiner, the result would have an immediate and direct
  42.  susceptibility to known-plaintext attack.  In my opinion, such
  43.  a cipher would be essentially worthless.  (I might add that the
  44.  network designers and technical managers might think that the
  45.  crypto design looks like enough of an improvement (over no
  46.  encryption) to actually implement.)
  47.  
  48.  
  49.  The Response
  50.  
  51.  Now consider the same design but with a Dynamic Substitution
  52.  combiner [1,2] instead of exclusive-OR:
  53.  
  54.       [ Basically, Dynamic Substitution can be thought of as Simple
  55.       (or polyalphabetic) Substitution where the content of the
  56.       substitution table(s) changes while ciphering.
  57.  
  58.       Typically, the table is permuted slightly after every
  59.       substitution operation (an inverse table is also permuted
  60.       during deciphering).
  61.  
  62.       Usually, the permutation is an exchange of the just-used
  63.       substitution element, with some element selected by the
  64.       confusion sequence. ]
  65.  
  66.  The content of the DynSub tables will be reset for each packet,
  67.  and the same sequence used for ciphering.  Identical messages
  68.  will produce identical output up to the first different byte.
  69.  Early different bytes will generally produce three table-entry
  70.  differences between the two similar messages; subsequent bytes
  71.  which use those entries will produce different ciphertext.
  72.  
  73.  In general, it would seem to be difficult for the opponent to
  74.  identify either the repeatedly-used confusion sequence, or to
  75.  construct the state of the DynSub tables at any time.  As far
  76.  as I can tell, the resulting cipher has some worth as a modest
  77.  network cipher.
  78.  
  79.  
  80.  The Result
  81.  
  82.  Within the context (that is, the tremendous limitations) of the
  83.  above design, the Dynamic Substitution combiner seems to provide
  84.  a significant level of security where exclusive-OR gave none.
  85.  While *I* would not *normally* consider such a design, it is
  86.  interesting in that the reasons for the given constraints are
  87.  fairly obvious, as are the motives for building such a system.
  88.  It is also interesting that *anything* could help out in this
  89.  (frustrating) crypto situation.
  90.  
  91.  
  92.  [1]  Ritter, T.  1990.  Substitution Cipher with Pseudo-Random
  93.       Shuffling: The Dynamic Substitution Combiner.  Cryptologia.
  94.       14(4): 289-303.  (October)
  95.  
  96.  [2]  Ritter, T.  1990.  Dynamic Substitution Combiner and
  97.       Extractor.  U.S. Patent 4,979,832, issued Dec. 25, 1990.
  98.  
  99.  ---
  100.  Terry Ritter   ritter@cactus.org
  101.  
  102.