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

From: Daniel Gustafsson <daniel(at)yesql(dot)se>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date: 2024-02-16 13:30:38
Message-ID: 2A1BCB90-2641-4348-8846-F34ABD484865@yesql.se
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> 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?

> 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.

--
Daniel Gustafsson

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bharath Rupireddy 2024-02-16 14:10:00 Re: Do away with zero-padding assumption before WALRead()
Previous Message Peter Eisentraut 2024-02-16 13:18:08 Re: table inheritance versus column compression and storage settings