home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #23 / NN_1992_23.iso / spool / sci / crypt / 3761 < prev    next >
Encoding:
Internet Message Format  |  1992-10-13  |  2.1 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!spool.mu.edu!sol.ctr.columbia.edu!destroyer!ncar!csn!news.uwyo.edu!jimkirk
  2. From: jimkirk@news.uwyo.edu
  3. Newsgroups: sci.crypt
  4. Subject: Re: mc100.zip (mcrypt)
  5. Message-ID: <1992Oct13.153653.261@news.uwyo.edu>
  6. Date: 13 Oct 92 15:36:52 MST
  7. References: <1992Oct13.864.271@ALMAC>
  8. Distribution: sci,world
  9. Organization: University of Wyoming - Laramie, WY
  10. Lines: 33
  11.  
  12. In article <1992Oct13.864.271@ALMAC>, keith.willis@almac.co.uk writes:
  13. > 
  14. >         I have come across an implementation of RSA distributed by a
  15. >         company in Wales, UK, which claims to perform RSA encryption
  16. >         on the entire file, rather than just on a session key for a
  17. >         conventional algorithm.  The program may be common knowledge,
  18. >         but it is the first time I have come across it.  It is called
  19. >         MCRYPT, and is distributed by a company called Digital
  20. >         Crypto as shareware.
  21. > 
  22. >         What puzzles me is that encryption is very fast - less than 2
  23. >         minutes for a 40k text file using a 250 digit key - but
  24. >         decryption is _glacial_ - over 3 hours for the same file on
  25. >         the same PC.
  26.  
  27. A common speedup is to use an extremely small encryption exponent, such
  28. as 3.  I believe Knuth even proposed this at one point.  Raising something
  29. to the third power is *VERY* much faster than raising to large powers.
  30. Unfortunately, a corresponding decryption exponent will necessarily (it
  31. seems) be very large, and the modular exponentiation will be correspondingly
  32. hugely slower.
  33.  
  34. The big problem with a small exponent is if you use it to communicate with
  35. more than "n" people, where "n" is the encryption exponent, but the details
  36. have been lost as I read the paper on that quite some time ago.
  37.  
  38. Also, if it is known by an enemy that many of your plaintext blocks
  39. happen to contain very small numbers (lots of leading zeros) then
  40. cubing it isn't different than cubing mod m.  Then just take the integer
  41. cube root, and you've decrypted that block.  Rare, though.  (In any case,
  42. avoid blocks equal to zero).
  43.  
  44. Jim Kirkpatrick       jimkirk@corral.uwyo.edu
  45.