home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1993 #1 / NN_1993_1.iso / spool / sci / crypt / 6516 < prev    next >
Encoding:
Text File  |  1993-01-08  |  1.6 KB  |  37 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!wupost!sdd.hp.com!swrinde!network.ucsd.edu!qualcom.qualcomm.com!servo.qualcomm.com!karn
  3. From: karn@servo.qualcomm.com (Phil Karn)
  4. Subject: Re: How fast is DES?
  5. Message-ID: <1993Jan8.063123.5194@qualcomm.com>
  6. Sender: news@qualcomm.com
  7. Nntp-Posting-Host: servo.qualcomm.com
  8. Organization: Qualcomm, Inc
  9. References: <1ihdcmINNslg@fbi-news.Informatik.Uni-Dortmund.DE>
  10. Date: Fri, 8 Jan 1993 06:31:23 GMT
  11. Lines: 24
  12.  
  13. In article <1ihdcmINNslg@fbi-news.Informatik.Uni-Dortmund.DE> muenx@heike.informatik.uni-dortmund.de (Holger Muenx) writes:
  14. >  Is it possible for a software solution to reach an encryption rate
  15. >of about 100kB/sec (read 100 * 1024 Byte not 100 * 1024 Bit per second)
  16. >on a typical PC (say, Intel 386DX 33MHz)?
  17.  
  18. Well, my DES code (ucsd.edu, /hamradio/packet/tcpip/crypto/des.tar.Z)
  19. when compiled and run on a 486DX-50 using GCC under 386BSD encrypts 1
  20. million 64-bit blocks (8 megabytes) in 90.5 seconds of CPU time.
  21. That's not quite the rate you want, and on a faster machine too.  Oh
  22. well.
  23.  
  24. I groveled over this code quite a bit when I wrote it, and I doubt
  25. there are any *major* improvements to be found that wouldn't either
  26. impair its portability or greatly increase memory requirements. On the
  27. other hand, adding inline assembler or (especially) precomputing some
  28. very big tables (megabytes) *can* definitely pay off. My Bellcore
  29. colleague Dave Feldmeier wrote a paper on this exact subject for Crypto
  30. a few years back when we were building fast UNIX password crackers;
  31. you might look it up. (Can't remember the year offhand).
  32.  
  33. Phil
  34.  
  35.  
  36.  
  37.