Post by hb Post by Stephen Hoffman
OpenVMS is fairly late to adopting file checksums, but the CHECKSUM
command does have an only-somewhat-stale SHA-1 checksum support as of V8.4.
Do you mind saying what that should be?
Use of SHA-2 and SHA-3 hashes would be typical, now.
If I'm going to be doing a checksum (message digest hash), best to use
a reasonably secure one. SHA-1 is somewhat stale.
SHA-1 collisions are known, and SHA-1 has been deprecated by US NIST.
As are collisions for the yet-older MD5. And we were doing AUTODIN-2
CRC32 collisions on OpenVMS a decade or two ago, as we suspected the
target folks were still using CHECKSUM.
One of the networks I sometimes use in more recent times is known for
dynamically modifying unencrypted (e.g. FTP-transferred) Windows
executables detected in the network file transfer traffic. Copy a file
via that network, and and it's distinctly possible to have the
executable image detected by an intermediate host and malware inserted
for free. Which also ties back to best using sftp or FTP via VPN, and
cryptographically secure hashes, and not insecure hashes and
unencrypted links. And yes, added malware would probably be detected by
AUTODIN-2 CRC32 offered by CHECKSUM, but if I'm adding a checksum
comparison, the overhead of SHA-2 or SHA-3 will be lost in the noise of
the network file transfer. And spoofing the AUTODIN-2 CRC32 is trivial.
And on the subject of use and misuse of cryptographic hashes, here's an
old article on message digest hashes and password hashes:
ps: $DEITY remind me to never click on a documentation link at the VSI
website. Who thought pointing to an in-browser Scribd-like
PDF-rendering tool at the HPE website was a good idea? Yuck.
Pure Personal Opinion | HoffmanLabs LLC