home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / security / misc / 1759 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.8 KB
  1. Xref: sparky comp.security.misc:1759 alt.security:4819 comp.unix.admin:6198
  2. Newsgroups: comp.security.misc,alt.security,comp.unix.admin
  3. Path: sparky!uunet!gatech!usenet.ins.cwru.edu!agate!spool.mu.edu!sdd.hp.com!news.cs.indiana.edu!noose.ecn.purdue.edu!mentor.cc.purdue.edu!purdue!spaf
  4. From: spaf@cs.purdue.EDU (Gene Spafford)
  5. Subject: Re: Tripwire release
  6. In-Reply-To: uri@watson.ibm.com's message of Fri, 13 Nov 1992 17:45:45 GMT
  7. Message-ID: <SPAF.92Nov15135742@uther.cs.purdue.EDU>
  8. Sender: news@mentor.cc.purdue.edu (USENET News)
  9. Organization: Department of Computer Sciences, Purdue University
  10. References: <BxMEuE.CwC@mentor.cc.purdue.edu>
  11.     <1992Nov13.174545.145856@watson.ibm.com>
  12. Date: Sun, 15 Nov 1992 18:57:42 GMT
  13. Lines: 41
  14.  
  15. In article <1992Nov13.174545.145856@watson.ibm.com> uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,) writes:
  16.  
  17.    Why not just prompt the user for the key, and encrypt the database?
  18.    You could have plugs for DES, IDEA, FEAL (for those not very much
  19.    security-concerned :-)...
  20.  
  21. Well, there are several reasons.  First, protecting the database by
  22. encryption won't prevent it from being deleted or truncated.  Nor will
  23. encryption protect the program itself.  For that, you need to have it
  24. on read-only media.
  25.  
  26. Second, if a key is required every time Tripwire is run, then there is
  27. no safe way to run the program out of "cron" every night or every few
  28. hours (or every month -- whatever).
  29.  
  30. Third, we wanted to ship a self-contained program that anyone could
  31. use without needing outside utilities (other than a compiler).  If we
  32. built in reliance on encryption, it would have required that we ship
  33. the encryption code with it -- something that we didn't want to do
  34. because of the incredibly stupid export control laws in the US and
  35. other places.  Furthermore, few people would be able to detect if the
  36. encryption code had been tampered with to introduce a backdoor or
  37. weakened form of the algorithm.
  38.  
  39. Fourth, there is a window of vulnerability to catching a key
  40. (password) using most encryption programs that are out there.  We
  41. believe that creating a read-only disk version of the database in
  42. single-user mode is safer.
  43.  
  44. Last of all, not every encryption routine that someone might use is
  45. very strong.  Thus, if we put the hooks in place for someone to drop
  46. something in, undoubtedly someone would drop in rot13 and think that
  47. their system was protected by Tripwire.  It would seem pretty silly to
  48. run every file through MD5 and Snefru, only to protect the results
  49. with a Caesar cipher, no?  Thus, we decided to encourage something we
  50. believe is less likely to get screwed up, although we suspect that
  51. many people won't pay attention to our recommendation as is...sigh.
  52.  
  53. Of course, by shipping the source code, a knowledgeable user can put
  54. in whatever other extensions and features they wish.  Our particular
  55. preferences and prejudices many not be appropriate for every site.
  56.