Thread

  1. BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    PG Bug reporting form <noreply@postgresql.org> — 2025-11-27T08:55:14Z

    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?
    
    
  2. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-11-27T16:01:07Z

    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
    
    
    
    
  3. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-27T17:51:43Z

    > 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
    
    
    
    
    
  4. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-28T09:26:44Z

    > 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
    
    
    
    
    
  5. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-28T09:56:27Z

    > 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
    
    
    
    
    
  6. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-28T11:07:54Z

    > 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
    
    
    
    
    
  7. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Tom Lane <tgl@sss.pgh.pa.us> — 2025-11-28T18:29:21Z

    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
    
    
    
    
  8. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-11-28T18:36:47Z

    > 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
    
    
    
    
    
  9. Re: BUG #19335: the function encrypt does not work correct - ERROR: encrypt error: Key was too big

    Daniel Gustafsson <daniel@yesql.se> — 2025-12-01T09:03:05Z

    > 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