Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Date
Msg-id 1832899.1601012204@sss.pgh.pa.us
Whole thread Raw
In response to Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
Responses Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2020-09-24 21:44, Daniel Gustafsson wrote:
>> Correct, IIUC in order to be FIPS compliant all cryptographic modules used must
>> be FIPS certified.

> As I read FIPS 140-2, it just specifies what must be true of
> cryptographic modules that claim to follow that standard, it doesn't say
> that all cryptographic activity in an application or platform must only
> use such modules.  (Notably, it doesn't even seem to define
> "cryptographic".)  The latter may well be a requirement of a user or
> customer on top of the actual standard.

Hm ... AFAICT, the intent of the "FIPS mode" in Red Hat's implementation,
and probably other Linux distros, is exactly that thou shalt not use
any non-FIPS-approved crypto code.  By your reading above, there would
be no need at all for a kernel-level enforcement switch.

> However, again, the SCRAM
> implementation would already appear to fail that requirement because it
> uses a custom HMAC implementation, and HMAC is listed in FIPS 140-2 as a
> covered algorithm.

Ugh.  But is there any available FIPS-approved library code that could be
used instead?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Feature improvement of tab completion for DEALLOCATE
Next
From: Peter Eisentraut
Date:
Subject: Re: vs formatting in the docs