Open JaggedJax opened 7 months ago
This change in response started in 8.1.27 and I don't think it's intentional, but I could be wrong about that.
I just tested it with latest 8.2 (using OpenSSL 1.1.1 and OpenSSL 3.0) as well as latest 8.1 (with OpenSSL 3.1.5) which is out of active support btw and I'm not able to re-create this locally. What OpenSSL version do you use (output of php --ri openssl
)? Do you see that only on Rocky Linux?
openssl
OpenSSL support => enabled OpenSSL Library Version => OpenSSL 1.1.1k FIPS 25 Mar 2021 OpenSSL Header Version => OpenSSL 1.1.1k FIPS 25 Mar 2021 Openssl default config => /etc/pki/tls/openssl.cnf
Rocky 8.9 has Active Support until May 31, 2024 and EOL on May 31, 2029
I didn't even think about the fact that openssl may have upgraded at the same time. Looking at my dnf history, I can see that openssl did have a version update at the same time as I performed the php update:
Upgrade openssl-1:1.1.1k-12.el8_9.x86_64 @baseos Upgraded openssl-1:1.1.1k-9.el8_7.x86_64 @@System
Hi, I just came accross the exact same problem on Ubuntu 22.04 with php 8.2.15 :
OpenSSL support => enabled OpenSSL Library Version => OpenSSL 3.0.2 15 Mar 2022 OpenSSL Header Version => OpenSSL 3.0.2 15 Mar 2022 Openssl default config => /usr/lib/ssl/openssl.cnf
Regards
fyi: https://github.com/openssl/openssl/commit/7fc67e0a33102aa47bbaa56533eeecb98c0450f7 man: https://www.openssl.org/docs/manmaster/man3/EVP_PKEY_decrypt.html
Since version 3.2.0, the EVP_PKEY_decrypt() method when used with PKCS#1 v1.5 padding doesn't return an error in case it detects an error in padding, instead it returns a pseudo-randomly generated message, removing the need of side-channel secure code from applications using OpenSSL.
backports:
That's very helpful information @ranvis, thanks.
Is there any way to check if encrypted data is properly formatted/valid before calling openssl_private_decrypt
? I don't see another function that can be used for that.
I was previously lazily using the result of openssl_private_decrypt
to check that input data was valid. Now I'm checking if the output is valid UFT-8 data, but that's a bit hacky (and sometimes the random data returned will be valid UTF-8).
It is not possible. Best solution is to use OPENSSL_PKCS1_OAEP_PADDING
. We will be soon updating docs with more info.
I believe message integrity cannot be validated with padding. OAEP is better though, still an extra MAC is preferred IMO.
Description
The following code:
Resulted in this output:
But I expected this output instead:
PHP Version
PHP 8.1.27
Operating System
Rocky Linux release 8.9 (Green Obsidian)