Article View: comp.security.misc
Article #696Re: Tripwire release
From: Gene Spafford
Date: Sun, 15 Nov 1992 18:57
Date: Sun, 15 Nov 1992 18:57
41 lines
2888 bytes
2888 bytes
In article <1992Nov13.174545.145856@watson.ibm.com> uri@watson.ibm.com (Uri Blumenthal,35-016,8621267,) writes: Why not just prompt the user for the key, and encrypt the database? You could have plugs for DES, IDEA, FEAL (for those not very much security-concerned :-)... Well, there are several reasons. First, protecting the database by encryption won't prevent it from being deleted or truncated. Nor will encryption protect the program itself. For that, you need to have it on read-only media. Second, if a key is required every time Tripwire is run, then there is no safe way to run the program out of "cron" every night or every few hours (or every month -- whatever). Third, we wanted to ship a self-contained program that anyone could use without needing outside utilities (other than a compiler). If we built in reliance on encryption, it would have required that we ship the encryption code with it -- something that we didn't want to do because of the incredibly stupid export control laws in the US and other places. Furthermore, few people would be able to detect if the encryption code had been tampered with to introduce a backdoor or weakened form of the algorithm. Fourth, there is a window of vulnerability to catching a key (password) using most encryption programs that are out there. We believe that creating a read-only disk version of the database in single-user mode is safer. Last of all, not every encryption routine that someone might use is very strong. Thus, if we put the hooks in place for someone to drop something in, undoubtedly someone would drop in rot13 and think that their system was protected by Tripwire. It would seem pretty silly to run every file through MD5 and Snefru, only to protect the results with a Caesar cipher, no? Thus, we decided to encourage something we believe is less likely to get screwed up, although we suspect that many people won't pay attention to our recommendation as is...sigh. Of course, by shipping the source code, a knowledgeable user can put in whatever other extensions and features they wish. Our particular preferences and prejudices many not be appropriate for every site.
Technical Details
Message-ID:
<SPAF.92Nov15135742@uther.cs.purdue.EDU>Path:
arc1-ca.pugleaf.net!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!spafReferences:
<BxMEuE.CwC@mentor.cc.purdue.edu> <1992Nov13.174545.145856@watson.ibm.com>Show Full Headers
Complete Article Headers
Newsgroups: comp.security.misc,alt.security,comp.unix.admin Path: arc1-ca.pugleaf.net!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 From: spaf@cs.purdue.EDU (Gene Spafford) Subject: Re: Tripwire release In-Reply-To: uri@watson.ibm.com's message of Fri, 13 Nov 1992 17:45:45 GMT Message-ID: <SPAF.92Nov15135742@uther.cs.purdue.EDU> Sender: news@mentor.cc.purdue.edu (USENET News) Organization: Department of Computer Sciences, Purdue University References: <BxMEuE.CwC@mentor.cc.purdue.edu> <1992Nov13.174545.145856@watson.ibm.com> Date: Sun, 15 Nov 1992 18:57:42 GMT Lines: 41