home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / sci / crypt / 3110 < prev    next >
Encoding:
Internet Message Format  |  1992-09-07  |  3.3 KB
  1. Path: sparky!uunet!ogicse!unmvax!cs.sandia.gov!mccurley
  2. From: mccurley@cs.sandia.gov (Kevin S. McCurley)
  3. Newsgroups: sci.crypt
  4. Subject: Re: SHS/SHA source code + random thoughts
  5. Keywords: SHS SHA message digest
  6. Message-ID: <1992Sep5.151837.14322@cs.sandia.gov>
  7. Date: 5 Sep 92 15:18:37 GMT
  8. Article-I.D.: cs.1992Sep5.151837.14322
  9. References: <1992Sep4.060230.28313@cs.aukuni.ac.nz>
  10. Sender: usenet@cs.sandia.gov (Another name for news)
  11. Organization: Sandia National Laboratories, Albuquerque, NM
  12. Lines: 63
  13.  
  14. In article <1992Sep4.060230.28313@cs.aukuni.ac.nz> Peter Gutmann (pgut1@cs.aukuni.ac.nz) writes:
  15. >SHA Speed
  16. >=========
  17. >
  18. >  I ran the SHA code against the distributed version of MD5 (which is
  19. >significantly less optimised than the SHA code).  The results were as follows:
  20. >
  21. >          25 MHz PClone     DECstation 2100     DECstation 5000
  22. >
  23. >    SHA         31 K/sec           120 K/sec           208 K/sec
  24. >    MD5         55 K/sec           169 K/sec           278 K/sec
  25. >
  26. >This comparison isn't 100% fair since the standard MD5 distribution is a
  27. >somewhat pessimal implementation (in fact an optimised PC version runs around 5
  28. >times faster).  An implementation of MD5 optimised to the level of SHA runs
  29. >around 2 times faster.
  30.  
  31. I too have written a version of SHA in C.  I have now tested it on
  32. numerous machines, but have not really optimized it for any (that
  33. would require assembly language - yuck).  My personal animosity for
  34. MS-DOG also prevented me from working hard on the PC version.  The
  35. biggest improvements from a C version are probably possible for
  36. little-endian machines like 80x86 machines.
  37.  
  38. Here are the results (all speeds are for hashing stuff from memory -
  39. the time to read a file slows them down by about 10%): If you think
  40. the choice of machines is bizarre - it's what I could find handy at
  41. the time.  I omitted the really rare machines!
  42.  
  43. machine                                  bytes/second
  44. ---------------------------------------------------------
  45. IBM RS/6000 530H, xlc -O                   1,098,000 
  46. SGI IRIS (33 MHz Model 4D340), cc -O3      1,038,200
  47. Sun Sparcstation 2, cc -O4                 1,009,000
  48. IBM RS/6000 530, xlc -O -Q                   832,600
  49. SGI IRIS (25 MHz Model 4D240), cc -O3        806,000
  50. DECstation 5000, cc -O4                      598,000
  51. Sun Sparcstation 1+, cc -O3                  507,000
  52. Sun Sparcstation 1, cc -O4                   498,000
  53. DECstation 3100, gcc -O2                     495,000
  54. NeXTstation cc -O                            347,000
  55. Gateway 2000 (50MHz 80486Dx2), gcc -O2       244,710
  56. Sequent Symmetry (Intel 386), cc -O4          87,128
  57. Zenith 386 (16MHz), gcc -O2                   81,761
  58. Gateway 2000, Turbo C 2.0                     57,569
  59. Zenith 386, Turbo C 2.0.                      17,700
  60.  
  61. The only direct comparision I see to Peter's figures are for the
  62. Decstation 5000, where my results are about a factor of 2.8 faster.
  63. This comparison may not be fair, since I don't know how Peter could
  64. find a better compiler for his, or maybe he is reading stuff from a
  65. file.
  66.  
  67. The only comparision I made to MD5 is using the code distributed by
  68. anonymous FTP from rsa.com, which ran about 15% faster than my SHA
  69. code on a Sparcstation 2.
  70.  
  71. As for judging the cryptographic strength of the two, only time will
  72. tell.  In the meantime, unless disaster strikes, SHA is likely to
  73. become SHS.
  74.  
  75. Kevin McCurley
  76. Sandia National Laboratories
  77.