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

From Daniel Gustafsson
Subject Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2
Date
Msg-id 951343C8-43C6-4EA8-A02E-03E71889F543@yesql.se
Whole thread Raw
In response to Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2  (Michael Paquier <michael@paquier.xyz>)
Re: scram-sha-256 broken with FIPS and OpenSSL 1.0.2  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
> On 24 Sep 2020, at 21:22, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Sep 24, 2020 at 1:57 PM Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> Depends on what one considers to be covered by FIPS.  The entire rest of
>> SCRAM is custom code, so running it on top of the world's greatest
>> SHA-256 implementation isn't going to make the end product any more
>> trustworthy.
>
> I mean, the issue here, as is so often the case, is not what is
> actually more secure, but what meets the terms of some security
> standard.

Correct, IIUC in order to be FIPS compliant all cryptographic modules used must
be FIPS certified.

> At least in the US, FIPS 140-2 compliance is a reasonably
> common need, so if we can make it easier for people who have that need
> to be compliant, they are more likely to use PostgreSQL, which seems
> like something that we should want.

The proposed patch makes SCRAM+FIPS work for 14, question is if we need/want to
try and address v10-13.

cheers ./daniel


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: Compatible defaults for LEAD/LAG
Next
From: Robert Haas
Date:
Subject: Re: fixing old_snapshot_threshold's time->xid mapping