[ale] File Integrity Check

[J. Reeves Hall]

If you wanted to be paranoid you could use the md5sum program. That's 160
bits, IIRC, of extremely difficult to fake data.

-Reeves

Benjamin Scherrey wrote:

> Since a checksum is, by definition, a hash, it will always be possible
> to make a checksum appear to be correct. Some, however, are better
> than others. I recall coding EPROMs to run during the POST process of
> an IBM PC which required a memory range to checksum to zero before it
> executed. The checksum was purposely simple and by adding $0xFF's to
> the end of the file you'd eventually get the checksum to wrap around
> to zero. A hash that considers file size and timestamp, as well as
> content will be more difficult to 'fake'. An even more secure
> mechanism would be to run two different checksum types on the file
> although this is probably theoretically the same as generating a
> checksum with twice the resulting bits with a truly randomizing
> algorithm. I'm not familiar with the 'sum' program. If all it does is
> add bytes together in the file then I'd say this was a completely
> inadequate mechanism. Better checksums make use of bit shifting and
> xor computations.
>
>         later,
>
>                 Ben Scherrey
>
> PS: Any of you math types are quite welcome to correct any
> misconceptions I may be propagating...
>
> Russell Enderby wrote:
> >
> > In pursuit of determining critical system files for modifications I was
> > thinking the checksum prog 'sum' would be sufficient.  Understanding
> > that time,date, and file size can be modified under the ext2fs/ufs
> > directory table.  Is it possible to also make the 'sum' checksum appear
> > to be correct?
> >
> > I was under the impression tripwire uses its own special checksum prog
> > to verify files, although would 'sum' be sufficient as well?  If not
> > does anyone know of better more thorough checksum app?