Blowfish decryption failure because of incorrect key length

[Jeremy Sowden]

The version of OpenSSL in Jammy (3.0.2) is affected by this issue: https://github.com/openssl/openssl/issues/18359. The upshot is that ciphertext created in Jammy cannot be decrypted by unaffected versions of OpenSSL and vice versa. For example, here we encrypt a plaintext in Jammy:

    $ cat plaintext.txt
    The quick brown fox jumps over the lazy dog
    $ openssl enc -provider legacy -bf-cfb -e -in plaintext.txt -out ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1
    $ cat ciphertext.asc
    tBL52uAegjMw+DQLL1ipaXQjDnX0KK72QyqMxU1MbuSIfchivPj/JOGWUOU=
    $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1
    The quick brown fox jumps over the lazy dog

If we then try to decrypt it in Debian Sid, we get:

    $ openssl enc -provider legacy -bf-cfb -d -in ciphertext.asc -a -K d5cca2db098c2ea2 -iv da5638ace83dcde1
    hex string is too short, padding with zero bytes to length
    �;S��\h<�Vɦyʄ(�g`Hrm^�[��u �"f�S�-9�u

This has been fixed upstream here: https://github.com/openssl/openssl/commit/1b8ef23e68b273bb5e59f60df62251153f24768d

[Adrien Nader (adrien)]

I'm going to mark this as duplicate of another bug which I have an overdue answer to provide.

But one important question: what is your actual usecase that is negatively impacted?

[Jeremy Sowden (a3a3el)]

At work, we still use Blowfish and we are in the process of moving some systems from CentOS 7 to Ubuntu Jammy. Until the migration is complete, we may have data encrypted on CentOS 7 that we want to decrypt on Jammy and vice versa. We could work around the bug by switching all the affected systems at once, but that would make the migration more complicated. Fixing the bug makes it simpler, so my plan is to create a
package for work with the upstream patch added to 3.0.2-0ubuntu1.12 -- ideally only as a stop-gap until there's an update from Canonical. :)