Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
От | Daniel Gustafsson |
---|---|
Тема | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL |
Дата | |
Msg-id | 2A1BCB90-2641-4348-8846-F34ABD484865@yesql.se обсуждение исходный текст |
Ответ на | Re: Replace current implementations in crypt() and gen_salt() to OpenSSL (Peter Eisentraut <peter@eisentraut.org>) |
Ответы |
Re: Replace current implementations in crypt() and gen_salt() to OpenSSL
|
Список | pgsql-hackers |
> On 16 Feb 2024, at 13:57, Peter Eisentraut <peter@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-complianteither, 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? > Maybe this should be done on the level of block ciphers. So if someone wanted to add a "crypt-aes" module, that wouldthen continue to work. That's a fair point, we can check individual ciphers. I'll hack up a version doing this. -- Daniel Gustafsson
В списке pgsql-hackers по дате отправления: