| From: | Peter Eisentraut <peter(at)eisentraut(dot)org> |
|---|---|
| To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
| Cc: | "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com>, "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 12:57:56 |
| Message-ID: | bdf58b2c-71da-4129-bb63-e6c4f62051ad@eisentraut.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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. 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2024-02-16 13:18:08 | Re: table inheritance versus column compression and storage settings |
| Previous Message | jian he | 2024-02-16 12:54:16 | Re: POC, WIP: OR-clause support for indexes |