home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2945 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  3.2 KB
  1. Path: sparky!uunet!elroy.jpl.nasa.gov!sdd.hp.com!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!pgut1
  2. Newsgroups: sci.crypt
  3. Subject: Thoughts on using a one-way hash function as a cipher
  4. Message-ID: <1992Aug19.072200.4768@cs.aukuni.ac.nz>
  5. From: pgut1@cs.aukuni.ac.nz (Peter Gutmann)
  6. Date: Wed, 19 Aug 1992 07:22:00 GMT
  7. Sender: pgut1@cs.aukuni.ac.nz (PeterClaus          Gutmann        )
  8. Organization: HPACK Conspiracy Secret Laboratory
  9. Lines: 71
  10.  
  11. A week or so ago I posted code for turning any one-way hash function into a CFB
  12. encryption algorithm.  I've looked at it a bit more, and made a few
  13. improvements (as well as fixing a bug in the original code).  To recap, the
  14. cipher used MD5 as its one-way function, with the resulting algorithm being
  15. called MDC.  The output of MDC was made key-dependant by replacing the
  16. predefined Mysterious Values with ones derived from a user-supplied key.
  17.  
  18. I believe that using a one-way hash function in this manner makes more sense
  19. than using a true cipher since, when used in CFB mode, the cipher is simply
  20. acting as a hash function anyway.
  21.  
  22. The transformation is in fact somewhat more complex than this, since MD5 uses
  23. both the 'input' and 'output' data in its transformation, and reduces 64 bytes
  24. of input to 16 bytes of output.  It works as follows:
  25.  
  26.       in[ 64 ] + out[ 16 ] -> out'[ 16 ]
  27.     data    previous MD   current MD
  28.  
  29. This problem is resolved by initially setting out[ 16 ] to the IV, and in[ 64 ]
  30. to zeroes.  Then, once the MDC constants have been set, we set in[ 64 ] to
  31. values derived from the key.  This means that even chosen plaintext attacks can
  32. only resolve 16 of 80 bytes of input.  Thus the best attack possible is a
  33. 20%-chosen plaintext attack (128 bits known, 512 bits unknown).  What we are
  34. doing is as follows (for a chosen-plaintext attack):
  35.  
  36.        [ 16 bytes ]  +  [ -------- 64 bytes -------- ]
  37.  
  38.     16 bytes -         64 bytes - derived from
  39.      chosen           encryption key and unknown
  40.       
  41.             |       |
  42.             +---------------+
  43.             |               |
  44.             |      MDC      |   Unknown one-way transformation
  45.             |               |
  46.             +---------------+
  47.             |       |
  48.             \       /
  49.               \   /
  50.                 v
  51.  
  52.               [ 16 bytes ]
  53.          
  54.                16 bytes -
  55.              known
  56.  
  57. We are transforming a 640-bit input value of which 128 bits are known, to a
  58. 128-bit output value via the MDC tranformation, a one-way hash function which
  59. is controlled by a user-supplied key.
  60.  
  61. In fact, this can be refined even further by using in[ 64 ] as the key, and
  62. repeatedly transforming out[ 16 ] to out'[ 16 ] with it (with the initial
  63. setting of out[ 16 ] being the IV value).
  64.  
  65. Thus we have two possibilities (with chosen-ciphertext attack shown below):
  66.  
  67.     in[ 64 ] + out[ 16 ] --MDC--> out'[ 16 ]
  68.     unknown     chosen   unknown    known
  69.  
  70. and
  71.  
  72.     in[ 64 ] + out[ 16 ] --MD5--> out'[ 16 ]
  73.     unknown     chosen    known     known
  74.  
  75. Question:  Is the use of the unknown-transformation MDC necessary?  In other
  76. words, do the 64 unknown bytes used with the known-transformation MD5 give
  77. enough security?  If they do, this has interesting possibilities, since MD5 is
  78. a MAC system and therefore not covered by the ITAR restrictions....
  79.  
  80. Comments, flames, etc to pgut1@cs.aukuni.ac.nz.
  81.  
  82.