From: Phillip Hallam-Baker <phill@xxxxxxxxxxxxxxx>
Sent: Wednesday, February 1, 2023 1:41 PM
To: Sands, Daniel <dnsands@xxxxxxxxxx>
Cc: openssl-users@xxxxxxxxxxx
Subject: [EXTERNAL] Re: MD5 and FIPS
You don't often get email from phill@xxxxxxxxxxxxxxx. Learn why this is important
Check out the recent vulnerability the NSA discovered in Microsoft CAPI, the attack uses an MD5 collision to introduce corrupted data into a cache.
This is the correct behavior and it is specified for good reason. If there is a FIPS requirement, it very likely prohibits MD5.
This is one of the many reasons we try to eliminate use of MD5 in specifications.
I know about the MD5 collision vulnerability and why it’s been downgraded from SECURE applications. I am not talking about a secure application of MD5. I am talking about file hashing for reasonable assurance that the file has not been corrupted by natural occurrences or transmission errors. We don’t even provide secret keying information, so it would be trivial for an “attacker” in this situation to simply hash the new contents and replace the checksum if so desired. That is true even if SHA512 were chosen. So as I say, this is not within the scope of FIPS.
It's worth noting that if FIPS compliance is configured at the OS level (which is a fairly likely environment to encounter if you're specifically developing a FIPS-compliant app), you will likely run into issues as soon as you try to run any non-FIPS-compliant algorithm, cryptography-related or not. We ran into this issue with a customer in the past when calculating file hashes with older algorithms.
On Wed, Feb 1, 2023, 7:16 PM Sands, Daniel via openssl-users <openssl-users@xxxxxxxxxxx> wrote:
