Re: Replace current implementations in crypt() and gen_salt() to OpenSSL - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Date
Msg-id 3af526e0-2294-4d68-8602-b781e1e75a08@eisentraut.org
Whole thread Raw
In response to Re: Replace current implementations in crypt() and gen_salt() to OpenSSL  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
List pgsql-hackers
On 20.02.24 11:09, Daniel Gustafsson wrote:
>> On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu) <shibagaki.koshi@fujitsu.com> wrote:
> 
>> Let me confirm the discussion in threads. I think there are two topics.
>> 1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
>> cipher (crypt-bf, etc...) in crypt() and gen_salt()
> 
> That level might be overkill given that any cipher not in the FIPS certfied
> module mustn't be used, but it's also not the wrong place to put it IMHO.

I think we are going about this the wrong way.  It doesn't make sense to 
ask OpenSSL what a piece of code that doesn't use OpenSSL should do. 
(And would that even give a sensible answer?  Like, you can configure 
OpenSSL to load the fips module, but you can also load the legacy module 
alongside it(??).)  And as you say, even if this code supported modern 
block ciphers, it wouldn't be FIPS compliant.

I think there are several less weird ways to address this:

* Just document it.

* Make a pgcrypto-level GUC setting.

* Split out these functions into a separate extension.

* Deprecate these functions.

Or some combination of these.




pgsql-hackers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: Change the bool member of the Query structure to bits
Next
From: Robert Haas
Date:
Subject: Re: A new message seems missing a punctuation