SHA1.EXE's status is uncertain. All versions before
and including v0.25b will fail for files >512MB.
With v0.26b onward, I introduced unsigned long long int
variables, which can store 64-bit quantities. This
change, happily, didn't break the program, but I'm unsure
as to whether it will now output the correct hash for
files > 512MB.  (It ought to.) SHA1.EXE still agrees
with Robert G. Durnal's SHA1.COM as to the hash
of the 300MB file pak0.pak from Half-Life, and they
both disagree with bokler.com's HASHcipher. The
HASHcipher program has been certified, but I do not
believe that the certification test involved huge
files. (The SHA-1 test vectors provided by the
gov't do not test huge files, for example.) Since
all three programs SHA1.EXE, SHA1.COM, and HASHcipher
agree for the 1,000,000 "a" file and 100,000,000 "a"
file, I believe that it is HASHcipher which is broken,
probably resulting from the use of signed long ints and
not unsigned long ints. (In this sense, HASHcipher is
more broken than even SHA1.EXE v0.25b.) Versions v0.28b
and upward *should* be fully SHA-1 compliant, even for
a 2^64 - 1 bit file. (That's some 2 exabytes, by the way.)
It will not report an error if you try to feed it a
2^64 bit file or larger, but then again, you've been
punished enough by having to store some 2^64 bits. :-P

v0.28b and above fixed a stupid problem with MASK32 that
could have corrupted hashes from any length input. NOW
it should be fully SHA-1 compliant.

SHA1.EXE v0.28b reports the hash of a 1,000,000,000
byte file consisting of all 'a' characters as:

D0F3E4F2 F31C665A BBD8F518 E848D5CB 80CA78F7

Which agrees with many other implementations.
 
- S.T.L.
