Re: Replace current implementations in crypt() and gen_salt() to OpenSSL

On 16.02.24 14:30, Daniel Gustafsson wrote:
>> On 16 Feb 2024, at 13:57, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>>
>> On 16.02.24 10:16, Daniel Gustafsson wrote:
>>>> 2. The crypt() and gen_salt() methods built on top of them (modes of operation, kind of) are not FIPS-compliant.
>>> I wonder if it's worth trying to make pgcrypto disallow non-FIPS compliant
>>> ciphers when the compiled against OpenSSL is running with FIPS mode enabled, or
>>> raise a WARNING when used? It seems rather unlikely that someone running
>>> OpenSSL with FIPS=yes want to use our DES cipher without there being an error
>>> or misconfiguration somewhere.
>>
>> I wonder on what level this kind of check would be done. For example, the password hashing done for SCRAM is not FIPS-compliant either, but surely we don't want to disallow that.
>
> Can you elaborate? When building with OpenSSL all SCRAM hashing will use the
> OpenSSL implementation of pg_hmac and pg_cryptohash, so it would be subject to
> OpenSSL FIPS configuration no?

Yes, but the overall methods of composing all this into secrets and
protocol messages etc. are not covered by FIPS.

>> Maybe this should be done on the level of block ciphers. So if someone wanted to add a "crypt-aes" module, that would then continue to work.
>
> That's a fair point, we can check individual ciphers. I'll hack up a version
> doing this.

Like, if we did a "crypt-aes", would that be FIPS-compliant? I don't know.