> On 20 Feb 2024, at 13:40, Peter Eisentraut wrote:
>
> On 20.02.24 12:39, Daniel Gustafsson wrote:
>> A fifth option is to throw away our in-tree implementations and use the
>> OpenSSL
>> API's for everything, which is where this thread started. If the effort to
>> payoff ratio is palatable
On 20.02.24 12:39, Daniel Gustafsson wrote:
A fifth option is to throw away our in-tree implementations and use the OpenSSL
API's for everything, which is where this thread started. If the effort to
payoff ratio is palatable to anyone then patches are for sure welcome.
The problem is that, as
> On 20 Feb 2024, at 13:24, Robert Haas wrote:
>
> On Tue, Feb 20, 2024 at 5:09 PM Daniel Gustafsson wrote:
>> A fifth option is to throw away our in-tree implementations and use the
>> OpenSSL
>> API's for everything, which is where this thread started. If the effort to
>> payoff ratio is
On 20.02.24 12:27, Robert Haas wrote:
I don't think the first two of these proposals help anything. AIUI,
FIPS mode is supposed to be a system wide toggle that affects
everything on the machine. The third one might help if you can be
compliant by just choosing not to install that extension, and
On Tue, Feb 20, 2024 at 5:09 PM Daniel Gustafsson wrote:
> A fifth option is to throw away our in-tree implementations and use the
> OpenSSL
> API's for everything, which is where this thread started. If the effort to
> payoff ratio is palatable to anyone then patches are for sure welcome.
> On 20 Feb 2024, at 12:18, Peter Eisentraut wrote:
> I think we are going about this the wrong way. It doesn't make sense to ask
> OpenSSL what a piece of code that doesn't use OpenSSL should do.
Given that pgcrypto cannot be built without OpenSSL, and ideally we should be
using the OpenSSL
> On 20 Feb 2024, at 12:27, Robert Haas wrote:
>
> On Tue, Feb 20, 2024 at 4:49 PM Peter Eisentraut wrote:
>> I think there are several less weird ways to address this:
>>
>> * Just document it.
>>
>> * Make a pgcrypto-level GUC setting.
>>
>> * Split out these functions into a separate
On Tue, Feb 20, 2024 at 4:49 PM Peter Eisentraut wrote:
> I think there are several less weird ways to address this:
>
> * Just document it.
>
> * Make a pgcrypto-level GUC setting.
>
> * Split out these functions into a separate extension.
>
> * Deprecate these functions.
>
> Or some combination
On 20.02.24 11:09, Daniel Gustafsson wrote:
On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu)
wrote:
Let me confirm the discussion in threads. I think there are two topics.
1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
cipher (crypt-bf, etc...) in crypt()
> On 20 Feb 2024, at 10:56, Koshi Shibagaki (Fujitsu)
> wrote:
> Let me confirm the discussion in threads. I think there are two topics.
> 1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
> cipher (crypt-bf, etc...) in crypt() and gen_salt()
That level might be
Let me confirm the discussion in threads. I think there are two topics.
1. prohibit the use of ciphers disallowed in FIPS mode at the level of block
cipher (crypt-bf, etc...) in crypt() and gen_salt()
2. adding new "crypt-aes" module.
If this is correct, I would like to make a patch for the
> On 16 Feb 2024, at 15:49, Peter Eisentraut wrote:
> Like, if we did a "crypt-aes", would that be FIPS-compliant? I don't know.
If I remember my FIPS correct: Only if it used a FIPS certified implementation,
like the one in OpenSSL when the fips provider has been loaded. The cipher
must be
On 16.02.24 14:30, Daniel Gustafsson wrote:
On 16 Feb 2024, at 13:57, Peter Eisentraut 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
> On 16 Feb 2024, at 13:57, Peter Eisentraut 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
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
On 2/16/24 04:16, Daniel Gustafsson wrote:
On 15 Feb 2024, at 16:49, Peter Eisentraut 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
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
Dear Peter
Thanks for the replying
> 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.
>
> 3. The implementations
> On 15 Feb 2024, at 16:49, Peter Eisentraut 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
On 15.02.24 13:42, Koshi Shibagaki (Fujitsu) wrote:
However, crypt() and gen_salt() do not use OpenSSL as mentioned in [2].
Therefore, if we run crypt() and gen_salt() on a machine with FIPS mode enabled,
they are not affected by FIPS mode. This means we can use encryption algorithms
disallowed
Hi
This is Shibagaki.
When FIPS mode is enabled, some encryption algorithms cannot be used.
Since PostgreSQL15, pgcrypto requires OpenSSL[1], digest() and other functions
also follow this policy.
However, crypt() and gen_salt() do not use OpenSSL as mentioned in [2].
Therefore, if we run crypt()
21 matches
Mail list logo
