> On 15 Feb 2024, at 16:49, Peter Eisentraut <pe...@eisentraut.org> wrote:

> 1. All the block ciphers currently supported by crypt() and gen_salt() are 
> not FIPS-compliant.
> 
> 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.

Something like the below untested pseudocode.

diff --git a/contrib/pgcrypto/pgcrypto.c b/contrib/pgcrypto/pgcrypto.c
index 96447c5757..3d4391ebe1 100644
--- a/contrib/pgcrypto/pgcrypto.c
+++ b/contrib/pgcrypto/pgcrypto.c
@@ -187,6 +187,14 @@ pg_crypt(PG_FUNCTION_ARGS)
                           *resbuf;
        text       *res;
 
+#if defined FIPS_mode
+       if (FIPS_mode())
+#else
+       if 
(EVP_default_properties_is_fips_enabled(OSSL_LIB_CTX_get0_global_default()))
+#endif
+               ereport(ERROR,
+                               (errmsg("not available when using OpenSSL in 
FIPS mode")));
+
        buf0 = text_to_cstring(arg0);
        buf1 = text_to_cstring(arg1);

Greenplum implemented similar functionality but with a GUC, fips_mode=<bool>.
The problem with that is that it gives the illusion that enabling such a GUC
gives any guarantees about FIPS which isn't really the case since postgres
isn't FIPS certified.

--
Daniel Gustafsson



Reply via email to