This reverts commit 94ee4f9834.
The commit was a bit too late to be included in PHP 8.2 RC1. Given it's a massive ABI break, we decide to postpone the change to PHP 8.3.
This function works in exactly the same way as openssl_cipher_iv_length
but for a key length. This is especially useful to make sure that the
right key length is provided to openssl_encrypt and openssl_decrypt.
In addtion the change also updates implementation of
openssl_cipher_iv_length and adds a test for it.
This adds support for ChaCha20-Poly1305 AEAD algorithm so it is possible
to use it in the same way as AES GCM and other AEAD algorithms. This is
available in OpenSSL 1.1.0+.
Despite commit 69c3f8c[1] claiming otherwise, there is no need for any
Windows specific implementation here. Users can use random_bytes(), if
they desire so.
[1] <69c3f8cbba>
Closes GH-9153.
This has only been done for Windows systems so far, and there was a
TODO comment about looping for larger values; that appears to be
overkill, though, since 2 million bytes should be sufficient for all
use cases, and if there is really the need for more, users can still
loop manually. Anyhow, checking the range upfront on all platforms
is clearer then silently casting to `int`.
We split the error message for the least possible BC break.
Closes GH-9126.
It introduces a single function to check file paths passed to OpenSSL
functions. It expands the path, check null bytes and finally does
an open basedir check.
Allow $tag to be null. This is the value that openssl_encrypt()
sets it to for non-AEAD ciphers, so we should also accept this
as an input to openssl_decrypt().
Prior to PHP 8.1, null was accepted in weak mode due to the special
treatment of null arguments to internal functions.
Switch default cipher for openssl_pkcs7_encrypt() and
openssl_cms_encrypt() from RC2-40 to AES-128-CBC.
The RC2-40 cipher is considered insecure and is not loaded by
default in OpenSSL 3, which means that these functions will
always fail with default arguments.
As the used algorithm is embedded in the result (which makes this
different from the openssl_encrypt() case) changing the default
algorithm should be safe.
Closes GH-7357.
Instead of deprecated low-level API.
A caveat here is that when using the high-level API, OpenSSL 3
requires that if the prime factors are set, the CRT parameters
are also set. See https://github.com/openssl/openssl/issues/16271.
As such, add CRT parameters to the manual construction test.
This fixes the last deprecation warnings in openssl.c, but there
are more elsewhere.
Now that the DSA/DH/EC keys are not created using the legacy API,
we can fetch the details using the param API as well, and not
run into buggy priv_key handling.
This is very similar to the DH case, with the primary difference
that priv_key is ignored if pub_key is not given, rather than
generating pub_key from priv_key. Would be nice if these worked
the same (in which case we should probably also unify the keygen
for FFC algorithms, as it's very similar).
All other private keys are exported in PKCS#8 format, while EC
keys use traditional format. Switch them to use PKCS#8 format as
well.
As the OpenSSL docs say:
> PEM_write_bio_PrivateKey_traditional() writes out a private key
> in the "traditional" format with a simple private key marker and
> should only be used for compatibility with legacy programs.
Instead construct a proper EVP_PKEY for the public key and
perform a derive operation.
Unfortunately we can't use a common code path here, because
EVP_PKEY_set1_encoded_public_key() formerly known as
EVP_PKEY_set1_tls_encodedpoint() does not appear to work with
DH keys prior to OpenSSL 3.
Rather than querying whether the EVP_PKEY contains private key
information, determine this at time of construction and store it
in the PHP object.
OpenSSL doesn't provide an API for this purpose, and seems
somewhat reluctant to add one, see
https://github.com/openssl/openssl/issues/9467.
To avoid using deprecated low-level APIs to determine whether
something is a private key ourselves, remember it at the point
of construction.
The recent fix for bug 52093 is not compatible with LibreSSL ≥ 2.7.0,
which we recognize as mostly OpenSSL 1.1.0 compatible, but they still
do not support `ASN1_INTEGER_set_int64()`.
Closes GH-7339.
With OpenSSL 3 ciphers may be registered, but not provided. Make
sure that openssl_get_cipher_methods() only returns provided
ciphers, so that "in_array openssl_get_cipher_methods" style
checks continue working as expected.
