[Info-vax] FTP FYI

[Stephen Hoffman]

On 2020-11-25 10:15:00 +0000, hb said:

> On 11/25/20 12:46 AM, Stephen Hoffman wrote:
>> 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.


Background:

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: 
https://krebsonsecurity.com/2012/06/how-companies-can-beef-up-password-security/ 


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