Apologies for not answering earlier; I wasn't available when I first saw your message.
FWIW, there's just been another report of the same issue with a different scenario but that's half-way between the "streaming" case and the "data at rest" one. The reason this fix is difficult to integrate in a stable release is because while we know we would introduce breakage, we do not and cannot know how much. Imagine even 100 Jammy machines which can talk together today; that's quite expected because they're on the same release. This change would break that unless every machine is upgraded at once which is not the case by default due to phasing of updates (and we want to phase openssl updates slowly because it's a very central component). While I really sympathetize with your issue, this is the stance of the Ubuntu project. Both including the fix and not including the fix are problematic unfortunately. One additional reason to not include the fix is that we're now close to Ubuntu 24.04. I realize you've reported this over a year ago but analysis, preparing a new verion, and the SRU process all take time. This is especially true for openssl which is central and which updates have caused issues several times. Ultimately I'd like to be able to keep Ubuntu releases updated with the latest openssl versions (no jump from 3.x to 3.x+1 though, merely 3.x.y to 3.x.y+1). This is not done at the moment because incompatibilities and issues in openssl are often found late but are also very painful. In order to do these, I will have to apply the same analysis and criteria to every change in the openssl releases to ensure package upgrades are safe and uneventful. Had this been in place for 22.04, this change would likely have been integrated when it was released in June because that was very close to the initial 22.04 release. If we want this to happen, we need to draw the line somewhere and stick to it. Unfortunately this change is on the other side of the line That's not to say that we cannot do anything for tinc or for others affected packages but rather that it won't be done in openssl. I see two ways to improve this, tinc side. 1) Switch to another cipher. Blowfish uses a 64-bit block size which is small and limits how much data can be safely encrypted with the same key ( https://en.wikipedia.org/wiki/Blowfish_(cipher)#Weakness_and_successors ). I guess this requires cooperation from the server which you might not control but it is the best long-term solution (and would also help performance because computing a MAC on top of BF is surprisingly expensive, and re-keying every n GB stalls data transfers and incurs a spike in latency). 2) Modify tinc because there's apparently a portable work-around as I've mentioned in https://github.com/gsliepen/tinc/issues/414#issuecomment-1741038601 . I think there's more context on the github openssl bug tracker. My time is scarce until the end of the year but I will gladly help with the packaging if needed. I don't know if it could be uploaded because there would be the same compatibility concern, this time with servers on 22.04. A PPA might be more appropriate and not too inconvenient since tinc development has stalled while openssl gets security updates every few months. It might also be possible to add a new ciphername/option just for that but I don't know how much work that would be without looking at tinc's code. Let me know if you are able to spend some time on this. By the way, even though a change in the C code just for tinc seems annoying, the knowledge gained could be used for other packaes and workloads too. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssl in Ubuntu. https://bugs.launchpad.net/bugs/1990216 Title: backport fix for "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" to Jammy Status in openssl package in Ubuntu: Fix Released Status in openssl source package in Jammy: In Progress Status in openssl source package in Lunar: Fix Released Bug description: === SRU information === [Meta] This bug was the fourth in a series of bugs for a single SRU. The "central" bug with the global information and debdiff is http://pad.lv/2033422 [Impact] Decryption for Blowfish with OFB and CFB modes fails due to using a key shorter than expected by default. Encryption will also use a key shorter than expected. Exchange of encrypted data from/to Jammy using BF OFB/CFB will therefore lead to decryption issues. [Test plan] On Focal, run the following and copy the output to your clipboard for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do echo "Test with ${cipher}" | openssl enc -${cipher} -k test -pbkdf2 -out "pouet.${cipher}"; done tar c pouet.bf-* | xz | base64 -w 60 You can also run this on Lunar or Mantic if you add "-provider legacy -provider default" to the "openssl enc" invocation. On Jammy, run the following and paste your clipboard base64 -d | xz -d | tar x for cipher in bf-cbc bf-cfb bf-ecb bf-ofb; do openssl enc -d -provider legacy -provider default -${cipher} -k test -pbkdf2 -d -in "pouet.${cipher}"; done Only "Test with bf-cbc" and "Test with bf-ecb" will be properly decrypted: the other two will result in garbage on screen. Here is the result of the enc + tar + xz + base64 on Focal (works with Lunar/Mantic too but you need to added ): /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARBdADgbyxDlZ/1Xd7bAmZw7 8pbqQTu5j8StVybo1p1B2ydBc5VcodF6fu0hEp801tvirgSFNMSAHk5HMN/w hCgU1BIr/nK51g3A3Lkdv7QNbaUw2ux1AmO/MpCLKLffCB9ElFZH4tuOS5AR m9CJMzi6LQOw9wytGKm2IK3Ph7WpU6JQ/3HJilffQwHbFLnukiWGpLNO5v0O D/4AJikrU9iemfChT0jXDbIRZ8a8VpVhJqu0u6eYOheVTqmSRiHHpIC/p1VA ecFb0mACF/TQhjxcMUWGSGO/mtof+VaLiyg0KB87GKlChfwXTEvgbNuP9hmu GL64VhX568Oy9EakSxlcXiIRk14kJKv0MdHQqY1R22wAACzqSr/nzpwqAAGs AoBQAACjzq5WscRn+wIAAAAABFla Here is the same but from Jammy if you want to test encryption on Jammy and decryption on Lunar/Mantic: /Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cf/ARFdADgbyxDlZ/1Xd7bAmZw7 8pbqQTu5j8StVybo1p1B2ydBc1zK4HR2g3CiLJet+R++nZy/gph6RscQ6hI3 HySjdDOFRfjIVttiNK3DvRsZb37r8SXkj/JCYWicZGjWPZxVE3OAZhEed5qe jrFv871QAbm4jVGD4oIc4cOb5V/xDN7KWgwEzpWQy6+tcfPm3KLPQvULx56N 2qQf60hP//p5EXS3RpCitUsrGUoYzTynjOUIRy2yCmgZDh62RmchUshyWePa k0nEYlDbl5/dSHXbWEWESqW+QDj136MZRwQRY+QC4MvLXg2Bo8H+Dl/xvNDF /5J4layZdFlh76lWOtFRVoIbX6JtpAP34g4zx1422GSNAAAAAABRzyqPdCqX 1AABrQKAUAAABh3ynbHEZ/sCAAAAAARZWg== The contents are expected to be different due to the use of randomness. Don't try to compare the base64 outputs: I'm only using them to ease testing across containers. [Where problems could occur] This patch makes openssl match the documented default (see "man openssl-enc" and search for "Blowfish" for instance) and fixes decryption from an up-to-date Jammy to pretty much everything else, but it also create an issue for data encrypted on Jammy without this patch and Jammy with this patch. There are two possible cases: encrypted data being streamed across this boundary or data at rest being transferred or read later. Streaming is probably not an issue in practice because it's rather the current situation that has been an issue and it's easy to remedy by updating everything (which is relatively few machines since that's only Jammy and not any other OS or distribution). Data at rest is more annoying since updating Jammy will make it impossible to read the data again without updates to other pieces of software. That sounds like a really bad thing and it kind of is but at the same, the benefits are much larger than the issues. Indeed, there is already an incompatibility at the moment between Jammy and everything else and the more time passes by, the more such problematic files can be created. Luckily very few people are using blowfish nowadays and it's not even enabled by default anymore in openssl. Moreover the software update to work around the issue should be a single API call which is documented in the upstream bug report ( https://github.com/openssl/openssl/issues/18359 ). Finally, I have warned the two projects that I am aware are impacted; this is made easier by the fact that they encountered the initial incompatibility. [Patches] The patches come directly from upstream and apply cleanly. https://github.com/openssl/openssl/issues/18359 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0001-Fix-regression-in-default-key-length-for-Blowfish-CF.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 * https://git.launchpad.net/~adrien-n/ubuntu/+source/openssl/tree/debian/patches/jammy-sru-0002-Test-the-default-key-length-of-the-Blowfish-ciphers.patch?h=jammy-sru&id=04ef023920ab08fba214817523fba897527dfff0 === Original description === OpenSSL upstream implemented a fix for their issue #18359 "OpenSSL 3 cannot decrypt data encrypted with OpenSSL 1.1 with blowfish in OFB or CFB modes" https://github.com/openssl/openssl/issues/18359 as of libssl3 3.0.4 (and thus it is included in recent libssl3 versions in Kinetic). Could this fix be backported to libssl3 in Jammy? To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1990216/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
