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

From: "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>
To: 'Daniel Gustafsson' <daniel(at)yesql(dot)se>, Peter Eisentraut <peter(at)eisentraut(dot)org>
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-16 11:35:41
Message-ID: TYCPR01MB1168485BDD0392462C7D1D79CFA4C2@TYCPR01MB11684.jpnprd01.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Dear Daniel

Thanks for your reply.

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

Indeed, users do not use non-FIPS compliant ciphers in crypt() and gen_salt()
such as DES with FIPS mode enabled.
However, can we reduce human error by having these functions make the judgment
as to whether ciphers can or cannot be used?

If pgcrypto checks if FIPS enabled or not as in the pseudocode, it is easier to
achieve than replacing to OpenSSL.
Currently, OpenSSL internally determines if it is in FIPS mode or not, but would
it be a problem to have PostgreSQL take on that role?

-----------------------------------------------
Fujitsu Limited
Shibagaki Koshi
shibagaki(dot)koshi(at)fujitsu(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2024-02-16 11:56:13 Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
Previous Message Koshi Shibagaki (Fujitsu) 2024-02-16 11:32:44 RE: Replace current implementations in crypt() and gen_salt() to OpenSSL