🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.security.misc
Article #696

Re: Tripwire release

#696
From: Gene Spafford
Date: Sun, 15 Nov 1992 18:57
41 lines
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!spaf
References: <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