The question of whether or not non-FIPS-compliant algorithms should be allowed for non-cryptographic use is moot if you're deploying to environments requiring FIPS validation where the FIPS requirement is configured at the system level. A full audit of every line of code of every application present on the system(s) is completely infeasible. There is no reasonable way to ensure that people are using insecure algorithms "the right way" in cases where security is a primary concern. A blanket ban is the much more palatable option. And I can't think of a single case where one couldn't just as easily hash files using a compliant algorithm outside of support of legacy systems, in which case you'd have to go through the POAM/waiver process anyway. You'll have a hard time convincing anyone that an application under active development will undergo enough inconvenience by switching to a compliant hashing algorithm that they'd waiver you these days.
On Thu, Feb 2, 2023 at 7:00 AM Hubert Kario <hkario@xxxxxxxxxx> wrote:
On Thursday, 2 February 2023 01:45:00 CET, Sands, Daniel via openssl-users
wrote:
>
>> -----Original Message-----
>> From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> On Behalf Of Dr
>> Paul Dale
>> Sent: Wednesday, February 1, 2023 2:33 PM
>> To: openssl-users@xxxxxxxxxxx
>> Subject: [EXTERNAL] Re: MD5 and FIPS
>>
>> If you are using OpenSSL 1.0.2 and the old FOM, you're out of luck.
>>
>> If you are using OpenSSL 3.0 with the FIPS provider, you can
>> still access MD5 by
>> loading appropriate providers and specifying a property query. See the
>> migration or FIPS guides.
>
> This sounds like an acceptable workaround. So if I load the
> legacy provider, then request MD5 (or SHA1) explicitly through
> that provider, it should provide a working context?
For some old FIPS modules you can also re-enable the md5 hash by using
EVP_MD_CTX_set_flags(ctx, EVP_MD_CTX_FLAG_NON_FIPS_ALLOW);
Looking how Python handles the usedforsecurity keyword argument in hashlib
module is a usually a good idea.
--
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic
