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

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Daniel Gustafsson <daniel(at)yesql(dot)se>, "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>
Cc: "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-20 11:18:57
Message-ID: 3af526e0-2294-4d68-8602-b781e1e75a08@eisentraut.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 20.02.24 11:09, Daniel Gustafsson wrote:
>> On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu) <shibagaki(dot)koshi(at)fujitsu(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-02-20 11:20:27 Re: A new message seems missing a punctuation
Previous Message Tomas Vondra 2024-02-20 11:18:46 Re: Change the bool member of the Query structure to bits