HDTenEightyP/NetNews huggingface dataset:
From: hendefd@woof.duc.auburn.edu (Frank Henderson)
Newsgroups: comp.security.misc
Subject: SUMMARY hushlogin
Date: 28 Aug 92 13:01:00 GMT
Reply-To: hendefd@woof.duc.auburn.edu
Organization: Auburn University, AL

Thanks folks,
Apparently .hushlogin is/can be a good thing.
It is necessary to suppress non-essential login information
like motd and quota info so automatic logins (e.g. uucp
login script) don't get confused.

The security "risk" is the file is normally empty so anyone
who crashes your system can store stuff in there and you
probably won't ever look in it.

original message follows credits.

Thanks to:
Mark J. Sienkiewicz <ignatz@wam.umd.edu>
Brian Fitzgerald <fitzgb@mml0.meche.rpi.edu>
Adam Barclay <u9155376@cs.uow.edu.au>
jsm@theory.pppl.gov (John Scott McCauley Jr.)
dhesi@rahul.net (Rahul Dhesi)
adam@calliope.uucp (Adam Shostack)
casper@fwi.uva.nl (Casper H.S. Dik)
danisch@ira.uka.de (Hadmut Danisch )

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frank Henderson              \     /     E-mail: hendefd@tech.duc.auburn.edu
Network Technical Support     \ _ /       Auburn, AL
                           ----/_\----
               x--------------( . )--------------x
                    x|x   | |_|\_/|_| |   x|x     
                     x    x           x    x    

CF-18 Hornet (by Paul Tomblin pt@geovision.gvc.com)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>I checked the FAQ and searched all available posts and RT_M, but
>I can't find any info on hushlogin as mentioned in CERT-92:14 -->
>
>       2. If the check from (A.1) indicates that your binaries have been
>	   modified, check for the presence of a password
>	   log file.  Since the name of the logfile is often changed,
>	   the name of the file should be obtained using the
>	   "strings(1)" command on the Trojan login, uucpd, or telnet
>	   binary.  Examples of filenames used on other systems are:
>
>                               "/usr/spool/. " (dot space)
>                               "/var/spool/secretmail/.l"
>                               "/var/spool/secretmail/.log"
>                               "/var/spool/secretmail/.tty"
>                               "/var/spool/secretmail/.lock"
>                               "/usr/tmp/.log"
>                               "/usr/spool/uucp/.sys"
>                               "/usr/spool/uucppublic/.hushlogin"
>
>What is a .hushlogin file and why does my system have an empty 
>one in /usr/spool/uucppublic?
>
>thanks.
>
Newsgroups: comp.security.misc
From: danisch@ira.uka.de (Hadmut Danisch )
Subject: Re: hushlogin
Reply-To: danisch@ira.uka.de
Organization: Univ. Karlsruhe
Date: Fri, 28 Aug 1992 09:46:56 GMT

hendefd@woof.duc.auburn.edu (Frank Henderson) writes:


>What is a .hushlogin file and why does my system have an empty 
>one in /usr/spool/uucppublic?

'man login' gives the answer: When .hushlogin exists in the
home-directory of a user, login will not print out the 
message of the day, whether new mail arrived and the time
of the last login. This is mostly used to make life easier for
nonhuman users, such as uucp.


Hadmut





Newsgroups: comp.security.misc
From: rob@wzv.win.tue.nl (Rob J. Nauta)
Newsgroups: comp.security.misc
Subject: Re: Please subscribe me...
Date: 29 Aug 92 21:28:18 GMT
Distribution: comp.security.misc
Organization: Sex, UNIX & Rock 'n Roll

gs@mi.diab.se (Greger Sernemar) writes:

>Please subscribe me to this group...

>Thanks.

#######                           ###     ###     ###
#         ####    ####   #        ###     ###     ###
#        #    #  #    #  #        ###     ###     ###
#####    #    #  #    #  #         #       #       #
#        #    #  #    #  #
#        #    #  #    #  #        ###     ###     ###
#         ####    ####   ######   ###     ###     ###

-- 
/-----------------------------------------------\	Never		   ,==.
| Rob J. Nauta, UNIX computer security expert.	| 	 Apologize,	  /@  |
| rob@wzv.win.tue.nl, Phone: +31-40-837549	| 	  Never		 /_  <
| Feel free to email me for free advice		|	   Explain.	=" `g'
From: roose@dutiws.tudelft.nl (E.Roos Lindgreen.TI-tel-1670)
Newsgroups: comp.security.misc
Subject: 17 InfoSec Myths Debunked (RFI)
Keywords: security, ISSA
Date: 3 Sep 92 11:40:02 GMT
Organization: Delft University of Technology,The Netherlands

Hi there,

I'd be very grateful if anyone could provide me with a paper
or electronic copy of the following article:

	D. Parker
	"Seventeen Information Security Myths Debunked"
	Proc. 7th Annual ISSA Conference
	ISSA 1990

Our local library returned my request; they wanted to know whether
ISSA meant "International Symposium on Shipboard Acoustics" or
"International Symposium for the Study of Argumentation". ;-)

Edo Roos Lindgreen - phone +3115781670 - email roose@dutiws.twi.tudelft.nl
AIO - Operating Systems - Faculty of Technical Mathematics and Informatics
Delft University of Technology - Julianalaan 134 - Delft - The Netherlands
From: sxjcb@orca.alaska.edu (Jay C. Beavers)
Newsgroups: comp.security.misc
Subject: Hiding Processes from ps -ax
Date: 4 Sep 92 17:13:08 GMT
Followup-To: comp.security.misc
Organization: University of Alaska Computer Network


I've recently heard that you can hide a process from being displayed by a
ps -ax command.  Is this true, and if so what security implications does it
have?  How is this done, and what can be done to defeat it?

Thanks,
     - jcb

______________________________________________________________________________
                                        |    jay@seaspray.uacn.alaska.edu
Jay C. Beavers                          |    sxjcb@orca.alaska.edu
University of Alaska Computer Network   |    sxjcb@alaska.bitnet
________________________________________|_____________________________________
Newsgroups: comp.security.misc
From: frank@D012S436.sniap.mchp.sni.de ()
Subject: Re: Covert channel
Organization: Siemens-Nixdorf AG
Date: Thu, 27 Aug 92 08:09:47 GMT

jfh@rpp386.lonestar.org (John F. Haugh II) writes:
: violates the system's security policy."  If you are permitted to change
: the mail headers, doing so cannot violate the system's security policy.

So no security policy can ever be violated, because anything you may be
able to do must have been "permitted".  Cracked somebody's password?  
Well you were able to do it weren't you?  Doesn't violate the security 
policy then, does it?  

There is a difference between "security policy" (a written document),
its translation into system level parameters, and the *enforcement* of 
those parameters.

--
Frank O'Dwyer		       			Disclaimer: 
Siemens-Nixdorf AG 	                        I will deny everything
Tel.  : +49 (89) 636-40639                      Fax.  : +49 (89) 636-45860
e-mail: Frank.ODwyer@sniap.mchp.sni.de
Newsgroups: comp.security.misc
From: rjvega@netcom.com (Ric Vega)
Subject: Re: Disabling telnetd and ftpd for security
Date: Thu, 27 Aug 92 09:46:02 GMT
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 

In article <1992Aug27.174729.1@vcp1.vcp.monash.edu.au> daniel@vcp1.vcp.monash.edu.au writes:
>
>
>I thought that the best way to make the Iris secure and still allow network
>access would be to disable telnetd and ftpd, leaving inetd and smtpd working
>for mail to be available.  This would allow telnet and ftp *from* our Iris,
>but not *to*.
>
With inetd gone, no one would be able to telnet *to* your machine..
I think its telnetd you would need to disable along with the ftpd


Guy
gtvega@seabass.st.usm.edu
Eagles Nest BBS

>
>
From: cliff@cs.arizona.edu (Cliff Hathaway)
Newsgroups: comp.security.misc
Subject: Re: Physical Security - Macs & PCs
Date: 1 Sep 92 17:06:17 GMT
Organization: U of Arizona, CS Dept, Tucson

We have about 2 dozen Mac SE's, each with 2 floppy drives.  We have a
write-protected boot floppy in the top drive, and the user supplies his/her
own floppy in the lower drive.  We purchased sheet metal "chastity belts" that
have a slot to allow access to the lower drive, and a bit of foam rubber that 
causes the boot floppy to rebound back into the drive when it is ejected on
powerdown.  The contents of the boot diskette are copied to a RAMdisk at bootup,
and most of the programs are on a server, available via Appletalk.

As for physical security, these units have a hasp that fits over the snap-in
security ring on the back of the SE's, and we put a padlock through this ring
and a case-hardened chain, the other end of which is welded to the underside
of the worksurface.  By using the chain, we give the users some degree of
freedom to arrange the work area to suit their preferences.

We've had this setup for almost 3 years now, and we haven't had any problems
with either viruses or theft, except for a couple mouse pads that sprouted
legs.  I don't recall where we purchased these units, but I'm pretty sure
it was through an ad in one of the Mac trade rags.

-- 

    Cliff Hathaway
    Dept. of Computer Science (602)621-4291
    University of Arizona     cliff@cs.arizona.edu 	        (internet) 
    Tucson, Ariz. 85721	      {cmcl2,noao,uunet}!arizona!cliff	(uucp)
From: gs@mi.diab.se (Greger Sernemar)
Newsgroups: comp.security.misc
Subject: Please subscribe me...
Date: 28 Aug 92 14:04:20 GMT
Distribution: comp.security.misc
Organization: Diab Data AB, Sweden.

Please subscribe me to this group...

Thanks.

Greger Sernemar

--
-----------------------------------------------------------------------------
Greger Sernemar,  Diab Data AB   ####                    ####
SNAIL:  Box 2029                 #   # ###   #   ####    #   #   #  #####  #
        S-183 02 Taby, Sweden    #   #  #   # #  #   #   #   #  # #   #   # #
ANALOG: +46 8 638 94 00          #   #  #  #   # ####    #   # #   #  #  #   #
FAX:    +46 8 792 05 61          #   #  #  ##### #   #   #   # #####  #  #####
EMAIL:   gs@diab.se or           #   #  #  #   # #   #   #   # #   #  #  #   #
        mcvax!sunic!diab!gs      ####  ### #   # ####    ####  #   #  #  #   #
X400:  C=SE  ADMD=TeDe  PRMD=Diab  S=Sernemar   G=Greger
-----------------------------------------------------------------------------
Newsgroups: comp.security.misc
From: frank@D012S436.sniap.mchp.sni.de ()
Subject: Re: Covert channel
Organization: Siemens-Nixdorf AG
Date: Fri, 4 Sep 92 16:02:22 GMT

jfh@rpp386.lonestar.org (John F. Haugh II) writes:
: In article <1992Sep1.131202.3262@sniap.mchp.sni.de> frank@D012S436.sniap.mchp.sni.de writes:
: >Firstly, I'm not German, I'm Irish.  We have been speaking
: >English almost as long as you have, but with more success.
: 
: First, my family is Irish ;-)  Second, some of us own a dictionary ...

I have a german dictionary, but I can't speak german.  
Unfortunately, words you have to get the right order the in. :-)

: This is the old argument between "can" and "may".
: 
: You CAN break into the house with a crowbar. 
: You MAY break into the house with a crowbar.
: 
: These are not the same sentence.

I know.  I agree with what you *meant* to say.  I just disagree 
with what you *said*. (In the original post).

I'll stop this now, before I make some obvious grammatical goof,
and you hang me out wet to dry.  My own english is atrocious anyhow :-)

: 
: >  /
: >Slan leat.  Auf Wiedersehen.  (Have a good day).
: 
: Which isn't what "auf wiedersehen" means either ...

No, that was a translation for the linguistically challenged :-)

: -- 
: John F. Haugh II                   | "The US Government has the Midas Muffler
: Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
: UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
: Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard
--
Frank O'Dwyer		       			Disclaimer: 
Siemens-Nixdorf AG 	                        I will deny everything
Tel.  : +49 (89) 636-40639                      Fax.  : +49 (89) 636-45860
e-mail: Frank.ODwyer@sniap.mchp.sni.de <--Use this, reply-to is broken
Newsgroups: comp.security.misc
From: flaps@dgp.toronto.edu (Alan J Rosenthal)
Subject: Re: Hiding Processes from ps -ax
Date: 4 Sep 92 21:21:42 GMT

sxjcb@orca.alaska.edu (Jay C. Beavers) writes:
>I've recently heard that you can hide a process from being displayed by a
>ps -ax command.  Is this true, and if so what security implications does it
>have?  How is this done,

#include <stdio.h>
#include <string.h>

int main(argc, argv)
    int argc;
    char **argv;
{
    char *p;

    for (p = argv[0]; *p; p++)
	*p = 0;
    strcpy(argv[0], "rn");

    (void)getchar();  /* to allow you to see that ps reports "rn" */
    return(0);
}
From: masticol@cadenza.rutgers.edu (Steve Masticola)
Newsgroups: comp.security.misc
Subject: Re: Physical Security - Macs & PCs
Date: 4 Sep 92 00:26:44 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

I wrote a couple of days ago:

>Both Radio Shack and Staples sell hold-down kits for computers. I'm
>not really satisfied with the Staples kit (it has a really cheap lock,
>and the cable loop is to small to use a better one), but haven't
>checked out the Radio Shack yet.

Since then, I bought a hold-down kit made by Acco, and am very pleased
with it.  It cost about the same as the kit sold at Staples, and the
hardware (especially the lock!) was much superior. I found it in a
random storefront computer shop. (Staples can special-order the Acco
kit, but it costs more there than I paid for it.)

Still haven't seen the Shack's kit, but I believe it's a clone of the
one Staples sells.

- Steve (masticol@cs.rutgers.edu).
From: masticol@cadenza.rutgers.edu (Steve Masticola)
Newsgroups: comp.security.misc
Subject: Re: Physical Security - Macs & PCs
Date: 1 Sep 92 12:57:53 GMT
Organization: Rutgers Univ., New Brunswick, N.J.

Both Radio Shack and Staples sell hold-down kits for computers. I'm
not really satisfied with the Staples kit (it has a really cheap lock,
and the cable loop is to small to use a better one), but haven't
checked out the Radio Shack yet.

If you hear of others, could you please let me know too?

Thanks,
- Steve Masticola (masticol@cs.rutgers.edu).
From: vancamp@iscsvax.uni.edu
Newsgroups: comp.security.misc
Subject: Physical Security - Macs & PCs
Date: 31 Aug 92 20:32:40 -0500
Organization: University of Northern Iowa

I am looking for a way of securing computers in an unmonitored lab, either
through attaching them to the tables and/or some type of alarm system.  Any
ideas on the most effective combinations and/or specific devices or vendors
would be appreciated.  Thanks,

Doug Van Camp                           VANCAMP@UNI.EDU
Coordinator of ART/CAT Computer Lab     (319) 273-5934
College of Humanities & Fine Arts       University of Northern Iowa
Newsgroups: comp.security.misc
From: ucs_rjd@SHSU.EDU
Subject: Security Programs
Organization: Sam Houston State University, Huntsville, Texas
Reply-To: ucs_rjd@SHSU.EDU
Date: Sat, 29 Aug 1992 03:41:09 GMT
X-Posted-From: freya.shsu.edu
X-Posted-Through: sol.ctr.columbia.edu

I just got finished running a security program called COPS on my
HP9000 and it uncovered some nice security faults that I had to fix, but
I was wondering if there are any other programs like COPS or better 
programs than it or in fact any programs at all that will test my system
more.
Could you please email me some information on it please?
Thanks -- all help will be greatly appreciated.

Raphael Donato
Unix Systems Services
Sam Houston State University
Email: ucs_rjd@shsu.edu
From: gmeiers@edsi.plexus.COM (Garrett Meiers)
Newsgroups: comp.security.misc
Subject: Please subscribe me...
Date: 25 Aug 92 23:11:21 GMT
Article-I.D.: edsi.1992Aug25.231121.8411
Organization: Enterprise Data Systems Incorporated, Appleton WI

Please subscribe me to this group...

Thanks.

Garrett Meiers
gmeiers@edsi.plexus.com
From: jfh@rpp386.lonestar.org (John F. Haugh II)
Newsgroups: comp.security.misc
Subject: Re: Covert channel
Date: 2 Sep 92 12:41:04 GMT
Reply-To: jfh@rpp386.cactus.org (John F. Haugh II)
Organization: River Parishes Programming, Austin, Republic of Texas

In article <1992Sep1.131202.3262@sniap.mchp.sni.de> frank@D012S436.sniap.mchp.sni.de writes:
>Firstly, I'm not German, I'm Irish.  We have been speaking
>English almost as long as you have, but with more success.

First, my family is Irish ;-)  Second, some of us own a dictionary ...

permit vb permitted; permitting 1: to consent to : ALLOW 2 : to make possible

If the "security policy" "consented to" changing the headers (and we are
assuming that "mail" has faithfully implemented the security policy,
otherwise it is a bug and someone really should fix it ...), doing so is
NOT a violation of the "security policy".

This is the old argument between "can" and "may".

You CAN break into the house with a crowbar. 
You MAY break into the house with a crowbar.

These are not the same sentence.

>  /
>Slan leat.  Auf Wiedersehen.  (Have a good day).

Which isn't what "auf wiedersehen" means either ...
-- 
John F. Haugh II                   | "The US Government has the Midas Muffler
Ma Bell: (512) 251-2151            |  touch: everything they touch turns to
UUCP: ...!cs.utexas.edu!rpp386!jfh |  shit."
Domain: jfh@rpp386.cactus.org      |                  -- Jay Maynard
Newsgroups: comp.security.misc
From: daniel@vcp1.vcp.monash.edu.au
Subject: Disabling telnetd and ftpd for security
Organization: 
Date: Thu, 27 Aug 1992 07:47:29 GMT


We are in the process of being connected to the network.  Most connected
computers will be PC's used for mail and telnet and ftp. 
We have one Iris 4D which it would be really useful to have connected.
Our head of department is very concerned about security with regards
to academic/industrial espionage.

I thought that the best way to make the Iris secure and still allow network
access would be to disable telnetd and ftpd, leaving inetd and smtpd working
for mail to be available.  This would allow telnet and ftp *from* our Iris,
but not *to*.

Can anyone comment on the security of this measure.  Is there any likelihood
at all of an intruder when there is no telnetd or ftpd operating?

Thanks for your help,

Danny


Newsgroups: comp.security.misc
From: hendefd@woof.duc.auburn.edu (Frank Henderson)
Subject: hushlogin
Reply-To: hendefd@woof.duc.auburn.edu
Organization: Sun Microsystems, Inc.
Date: Thu, 27 Aug 1992 20:03:30 GMT

I checked the FAQ and searched all available posts and RT_M, but
I can't find any info on hushlogin as mentioned in CERT-92:14 -->

       2. If the check from (A.1) indicates that your binaries have been
	   modified, check for the presence of a password
	   log file.  Since the name of the logfile is often changed,
	   the name of the file should be obtained using the
	   "strings(1)" command on the Trojan login, uucpd, or telnet
	   binary.  Examples of filenames used on other systems are:

                               "/usr/spool/. " (dot space)
                               "/var/spool/secretmail/.l"
                               "/var/spool/secretmail/.log"
                               "/var/spool/secretmail/.tty"
                               "/var/spool/secretmail/.lock"
                               "/usr/tmp/.log"
                               "/usr/spool/uucp/.sys"
                               "/usr/spool/uucppublic/.hushlogin"

What is a .hushlogin file and why does my system have an empty 
one in /usr/spool/uucppublic?

thanks.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Frank Henderson              \     /     E-mail: hendefd@tech.duc.auburn.edu
Network Technical Support     \ _ /       Auburn, AL
                           ----/_\----
               x--------------( . )--------------x
                    x|x   | |_|\_/|_| |   x|x     
                     x    x           x    x    

CF-18 Hornet (by Paul Tomblin pt@geovision.gvc.com)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



Newsgroups: comp.security.misc
From: smith@sctc.com (Rick Smith)
Subject: Re: covert channels
Organization: SCTC
Date: Thu, 3 Sep 1992 15:51:29 GMT

fec@cbnewsl.cb.att.com (f.e.carey) writes:

>If file permission settings prevent me from reading the daily 
>files that contains records of production defects in the factory,
>the access controls forbiding such access could be
>said to be functioning.  Yet if I am able to determine
>the size of the files I can infer information about
>defect rates.  In such a case there would seem to be
>no "sending process". 
>Does such a scenario qualify as a covert channel?

No, because there is no attempt to place a "mandatory access control"
(MAC) boundary between you and the data. A properly implemented
mandatory access control boundary does not allow software on one side
to write things that are readable on the other. Since the size
information is visible, there isn't a real MAC boundary.

It's also important to distinguish between policy and implementation.
If the policy says "no defect info should be visible to outsiders"
then there's still the issue of whether or not someone seriously tries
to enforce that policy. In your example, the implementation is clearly
inadequate to enforce the specified access control requirement.

>Another scenario: If I've being held incommunicado in a
>building and denied access to phones, mail, etc. and I am 
>able to signal out a message using the venetian blinds, 
>Have I utilized a covert channel?

No, because covert channels have to do with electronic transmissions,
particularly ones that don't involve action by an interactive user.

The covert channel concept only makes sense in terms of MAC. Examples
based on conventional operating systems _without_ MAC really don't
work.

Rick.
smith@sctc.com            arden hills, minnesota
From: zen@death.corp.sun.com (d)
Newsgroups: comp.security.misc
Subject: Re: Disabling telnetd and ftpd for security
Date: 27 Aug 92 10:31:53
Organization: savage hackers
NNTP-Posting-Host: death.corp.sun.com
In-reply-to: daniel@vcp1.vcp.monash.edu.au's message of Thu, 27 Aug 1992 07:47:29 GMT


In article <1992Aug27.174729.1@vcp1.vcp.monash.edu.au> daniel@vcp1.vcp.monash.edu.au writes:
> I thought that the best way to make the Iris secure and still allow network
> access would be to disable telnetd and ftpd, leaving inetd and smtpd working
> for mail to be available.  This would allow telnet and ftp *from* our Iris,
> but not *to*.

  Just nuke inetd -- this kills off most of your networking services.
(Outgoing) ftp and mail still work fine.

> Can anyone comment on the security of this measure.  Is there any likelihood
> at all of an intruder when there is no telnetd or ftpd operating?

  Yes.  Any service that you run can be used to get in.  Typically,
though, you only really have to watch for things like windowing systems,
yellow-pages or rpc-like services, NFS, home grown daemons or anything
that gets started (and stays running, obviously) in your rc files (or
whatever the iris uses, can't remember if it's sysV or not WRT that)
etc.

 -- d
Newsgroups: comp.security.misc
From: ignatz@wam.umd.edu (Mark J. Sienkiewicz)
Subject: Re: DES algorithm
Keywords: des encryption checksum
Organization: University of Maryland, College Park
Date: Wed, 26 Aug 1992 16:28:42 GMT

In article <930@gofish.Stars.Reston.Unisys.COM> dymm@gofish.NoSubdomain.NoDomain (David Dymm) writes:
>Folks,
>
>I would like to use DES to encrypt some data files.
>Essentially, I am using des as a checksum to ensure that
>files are not unintentionally changed.
               ^^^^^^^^^^^^^^^

It might be more practical to just remove read permissions from the
file.  If you want something more than that, try using a CRC.  It's
*much* faster.  It also has the advantage that the file can still be
read as plaintext.

But suppose you really want to encrypt the files...

>  However, I have users who telnet use my system via
>remote AFS, which means that they must have des on their system
>in order to decrypt my data files.  See the problem?  I can not
>require my users to reconfigure their kernal just so that they
>can use des.  Is their another solution?

You can also implement the DES algorithm in software.  That would
work on any machine without and kernel configuration, but would be
slower.  You could probably find one available for anonymous ftp
through archie.

I would still recommend the CRC approach, unless you are actively trying
to keep other people from understanding the files contents.