Обсуждение: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

The following bug has been logged on the website:

Bug reference:      19335
Logged by:          Marco Lebahn
Email address:      marco.lebahn@kfw.de
PostgreSQL version: 16.11
Operating system:   SUSE Linux Enterprise Server 15 SP7
Description:

Hello,

we patched our Systems from 16.10 and 14.19 to the new minor-level 16.11 and
14.20.

No problems with 16.10 and 14.19 while we using the function encrypt and
decrypt

psql (16.10)
Type "help" for help.

postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
                      encrypt
----------------------------------------------------
 \x74a761b105fbc8f535f666e952e00018deb1349fbf27a87b
(1 row)

postgres=# SELECT
convert_from(decrypt('\x74a761b105fbc8f535f666e952e00018deb1349fbf27a87b',
'thelongkeyfoobar', 'bf'),'SQL_ASCII');
    convert_from
--------------------
 sdafgsdfgsdafgasdf
(1 row)

postgres=#


After patching the function throws errors

postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
ERROR:  encrypt error: Cipher cannot be initialized
postgres=# SELECT
convert_from(decrypt('\x74a761b105fbc8f535f666e952e00018deb1349fbf27a87b',
'thelongkeyfoobar', 'bf'),'SQL_ASCII');
ERROR:  decrypt error: Cipher cannot be initialized
postgres=#


or here an other error

with 16.10 - No trouble
psql (16.10)
Type "help" for help.

postgres=#  SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar1234',
'bf');
                      encrypt
----------------------------------------------------
 \x9e8f9e9319266c9722f5803684c29ab16ee98d100cbfe350
(1 row)

trouble with 16.11

psql (16.11)
Type "help" for help.

postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar1234',
'bf');
ERROR:  encrypt error: Key was too big
postgres=# SELECT
convert_from(decrypt('\x9e8f9e9319266c9722f5803684c29ab16ee98d100cbfe350',
'thelongkeyfoobar1234', 'bf'),'SQL_ASCII');
ERROR:  decrypt error: Key was too big
postgres=#

Is this a bug?

PG Bug reporting form <noreply@postgresql.org> writes:
> we patched our Systems from 16.10 and 14.19 to the new minor-level 16.11 and
> 14.20.
> No problems with 16.10 and 14.19 while we using the function encrypt and
> decrypt
> After patching the function throws errors

These examples work fine for me in 16.11, and nothing in the
contrib/pgcrypto source code changed between 16.10 and 16.11.

Since pgcrypto depends on OpenSSL, one possible theory is that
your new pgcrypto.so was built against a different version of
OpenSSL than what is installed on your machine.  But with no
info about how you did the update, that's only wild speculation.

            regards, tom lane

> On 27 Nov 2025, at 09:55, PG Bug reporting form <noreply@postgresql.org> wrote:

> postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
> ERROR:  encrypt error: Cipher cannot be initialized

Is the new binary running against a FIPS enabled OpenSSL?

--
Daniel Gustafsson

> On 28 Nov 2025, at 10:22, <Marco.Lebahn@kfw.de> <Marco.Lebahn@kfw.de> wrote:

> ~> openssl version -a
> OpenSSL 3.2.3 3 Sep 2024 (Library: OpenSSL 3.2.3 3 Sep 2024)

Have you enabled, or recently disabled, the legacy provider in your openssl
config?  IIRC blowfish requires the non-default legacy provider to be added
since OpenSSL 3.0 IIRC.

--
Daniel Gustafsson

> On 28 Nov 2025, at 10:31, <Marco.Lebahn@kfw.de> <Marco.Lebahn@kfw.de> wrote:
>
> We don't change anything in the openssl packages or config - we patch only the postgresql-server from 16.10 to 16.11
>
> aes works fine - bf does not work anymore

Then something has changed in your OpenSSL environment without your knowing,
either via the packaging or externally to that.  Below I run PostgreSQL 16.11
with OpenSSL 3.0 without the legacy provider:

$ openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.0.9
    status: active

$ psql postgres
psql (16.11)
Type "help" for help.

postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
ERROR:  encrypt error: Cipher cannot be initialized

Now with the legacy provider enabled:

$ openssl list -providers
Providers:
  default
    name: OpenSSL Default Provider
    version: 3.0.9
    status: active
  legacy
    name: OpenSSL Legacy Provider
    version: 3.0.9
    status: active

$ psql postgres
psql (16.11)
Type "help" for help.

postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
                      encrypt
----------------------------------------------------
 \x74a761b105fbc8f535f666e952e00018deb1349fbf27a87b
(1 row)

--
Daniel Gustafsson

> On 28 Nov 2025, at 11:38, <Marco.Lebahn@kfw.de> <Marco.Lebahn@kfw.de> wrote:
>
> It seems that < 16.11 does and not check if I use "bf" from legacy provider

postgres does not consider which providers are loaded at all, since we support
OpenSSL 1.1.1+ the code doesn't even know of the provider concept.  Further,
pgcrypto in v16 hasn't been changed at all since January 2024.  If 16.10 allows
blowfish and 16.11 doesn't then, as Tom suggested upthread, you need to look at
which OpenSSL pgcrypto.so is linked against and how they are configured.

> :~> openssl list -providers
> Providers:
>  default
>    name: OpenSSL Default Provider
>    version: 3.2.3
>    status: active
>
> :~> psql postgres
> psql (16.10)
> Type "help" for help.
>
> postgres=# SELECT encrypt('sdafgsdfgsdafgasdf', 'thelongkeyfoobar', 'bf');
>                      encrypt
> ----------------------------------------------------
> \x74a761b105fbc8f535f666e952e00018deb1349fbf27a87b
> (1 row)

The above pgcrypto is highly unlikely to run against the same OpenSSL instance
(lib + configuration) in that case, note this from the OpenSSL 3.0 changelog:

  * Moved all variations of the EVP ciphers CAST5, BF, IDEA, SEED, RC2,
    RC4, RC5, and DES to the legacy provider.

OpenSSL doesn't support blowfish without the legacy provider loaded.  Your
16.10 is most likely linked against another version of OpenSSL, or at least
using another OpenSSL configuration/openssldir.

--
Daniel Gustafsson

Daniel Gustafsson <daniel@yesql.se> writes:
> On 28 Nov 2025, at 11:38, <Marco.Lebahn@kfw.de> <Marco.Lebahn@kfw.de> wrote:
>> It seems that < 16.11 does and not check if I use "bf" from legacy provider

> OpenSSL doesn't support blowfish without the legacy provider loaded.  Your
> 16.10 is most likely linked against another version of OpenSSL, or at least
> using another OpenSSL configuration/openssldir.

It seems quite odd that this changed at a minor PG version update.
I wonder if there was an upgrade of the underlying platform at the
same time, or if the new version was built by a different packager.

I confirmed on a fresh Fedora installation (with OpenSSL 3.2.6)
that it works as Daniel described.  Blowfish and other old ciphers
don't work with the out-of-the-box OpenSSL configuration, but if
you edit `openssl info -configdir`/openssl.cnf and uncomment the
lines that enable the legacy provider, it will work.  (I found
I had to restart the PG server, too --- apparently we only absorb
that configuration at postmaster start.  Didn't think to try
"pg_ctl reload"; perhaps that would have been enough.)

Of course the real bottom line here is you should be migrating
away from use of these ciphers.  There's a reason they are
deprecated and intentionally made hard-to-reach.

            regards, tom lane

> On 28 Nov 2025, at 19:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Daniel Gustafsson <daniel@yesql.se> writes:
>> On 28 Nov 2025, at 11:38, <Marco.Lebahn@kfw.de> <Marco.Lebahn@kfw.de> wrote:
>>> It seems that < 16.11 does and not check if I use "bf" from legacy provider
>
>> OpenSSL doesn't support blowfish without the legacy provider loaded.  Your
>> 16.10 is most likely linked against another version of OpenSSL, or at least
>> using another OpenSSL configuration/openssldir.
>
> It seems quite odd that this changed at a minor PG version update.
> I wonder if there was an upgrade of the underlying platform at the
> same time, or if the new version was built by a different packager.

Agreed, there must have been something else changing at the same time.

> I confirmed on a fresh Fedora installation (with OpenSSL 3.2.6)
> that it works as Daniel described.  Blowfish and other old ciphers
> don't work with the out-of-the-box OpenSSL configuration, but if
> you edit `openssl info -configdir`/openssl.cnf and uncomment the
> lines that enable the legacy provider, it will work.

Thanks for confirming!

--
Daniel Gustafsson

> On 1 Dec 2025, at 07:54, marco.lebahn@kfw.de wrote:
> 
> Hi Tom, hi Daniel,
> 
> many thanks for your help.
> 
> That's the point
> 
> with 16.10
> 
> ldd /usr/pgsql-16/lib/pgcrypto.so
> [...]
>        libcrypto.so.1.1 => /usr/lib64/libcrypto.so.1.1 (0x00007f9337e00000)
> [...]
> ~> rpm -qf /usr/lib64/libcrypto.so.1.1
> libopenssl1_1-1.1.1w-150700.11.6.1.x86_64
> 
> 
> with 16.11
> 
> ldd /usr/pgsql-16/lib/pgcrypto.so
> [...]
>        libcrypto.so.3 => /usr/lib64/libcrypto.so.3 (0x00007ff33a400000)
> [...]
> ~> rpm -qf /usr/lib64/libcrypto.so.3
> libopenssl3-3.2.3-150700.5.21.1.x86_64
> 
> that's the trigger

Your surprise is quite warranted, that's an unconventional change in a minor
revision of a package.

> uncomment legacy in opensslconfig + restart  = it works.

Thanks for confirming, I'm glad we could help.

> Be that as it may, we will avoid legacy in the future.

There is that, at least you are now using a non-EOL version of OpenSSL, which
is a silverlining here.

--
Daniel Gustafsson