home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / security / misc / 1762 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.0 KB
  1. Xref: sparky comp.security.misc:1762 alt.security:4822 comp.unix.admin:6205
  2. Path: sparky!uunet!olivea!spool.mu.edu!agate!doc.ic.ac.uk!uknet!keele!nott-cs!lut.ac.uk!
  3. From: jon_care@hicom.lut.ac.uk
  4. Newsgroups: comp.security.misc,alt.security,comp.unix.admin
  5. Subject: Re: Tripwire release
  6. Message-ID: <1992Nov14.033909.11404@lut.ac.uk>
  7. Date: 14 Nov 92 03:39:09 GMT
  8. References: <1992Nov6.161125.10283@ghost.dsi.unimi.it> <1992Nov06.173036.28994@watson.ibm.com> <BxMEuE.CwC@mentor.cc.purdue.edu>,<1992Nov13.004708.26881@cs.sandia.gov>
  9. Sender: @lut.ac.uk
  10. Reply-To: jon_care@hicom.lut.ac.uk
  11. Organization: Hicom Sevices
  12. Lines: 24
  13. Nntp-Posting-Host: hicom.lut.ac.uk
  14.  
  15. In article <1992Nov13.004708.26881@cs.sandia.gov>, mccurley@cs.sandia.gov (Kevin McCurley) writes:
  16. >uri@watson.ibm.com (Uri Blumenthal) writes:
  17. >>    Tripwire supports hooks for up to ten signature routines.  We
  18. >>ship it with MD5, Snefru, CRC32, CRC16, MD4, and MD2.  Although
  19. >>the CRC routines are not "signatures" in the cryptographic sense,
  20. >>they are nice to have since they are considerably faster than the
  21. >>more secure algorithms -- which are (hopefully) one-way hash
  22. >>functions.
  23. >
  24. >I stated earlier that NONE of these, including MD5, Snefru, and MD4,
  25. >are signatures in the cryptographic sense.  A true signature would
  26. >require something like RSA or DSA layered on a one-way hash function
  27. >like MD5 or SHA.  This would not significantly impact the speed, since
  28. >RSA on my Sparc would add less than .01 seconds, whereas MD5 runs at
  29. >about a megabyte per second.  Hence as soon as the file is bigger than
  30. >10K, the hash will take longer than the signature.  DSA verification
  31. >will take considerably longer, but I have an implementation that does
  32. >the verification in less than .3 seconds - still acceptable for many
  33. >applications.  If this is too slow for checking 100 files on a UNIX
  34. >system, then you can apply the hash to a large subset of the files
  35. >before finishing with the signature.
  36. >
  37. >Kevin McCurley
  38. >Sandia National Laboratories
  39.