On 16.02.24 14:30, Daniel Gustafsson wrote:
On 16 Feb 2024, at 13:57, Peter Eisentraut <pe...@eisentraut.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?
Yes, but the overall methods of composing all this into secrets and
protocol messages etc. are not covered by FIPS.
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.
Like, if we did a "crypt-aes", would that be FIPS-compliant? I don't know.
