Hello Ignace, list,
About the encoding API RFC: https://wiki.php.net/rfc/data_encoding_api
I think this API can have a positive impact of security of PHP applications:
- the current base64_decode is very tolerant towards invalid input, causing both functional and security problems: https://github.com/php/php-src/issues/20187
- the proposed base58 and URL-safe base64 encode make it easier to create secure tokens that are easy to use.
The RFC contains several errors in its examples. For example in the base16 encoding, $encodedWithSpaces contains "2c", a comma, but the decoded string does not contain a comma. I did my best to correct these issues in this repository: https://github.com/Sjord/php-encoding-rfc-examples
One of the examples calls base85_decode with DecodingMode::Forgiving. However, the signature of the base85_decode function (under "The following Base85 functions are added") does not have this parameter. Should it have this parameter?
The RFC proposes an option to choose a constant-time implementation. I am not sure whether this is a good idea. Constant-time algorithms are pretty difficult to develop and maintain. The benefit is questionable: for these types of timing attacks, the attacker needs to be able to run code on the same CPU as the victim application, which is not really common in how PHP is used. If we would support this, I think it would be better to forward it internally to libsodium or openssl, instead of developing this within PHP.
LLMs and I have created an implementation here: https://github.com/php/php-src/pull/23195. This was meant to experiment with the API and try out the RFC, and not necessarily as the actual implementation that gets finalized and merged.
For a while I also considered whether to support the base85 algorithm specified in RFC 1924 https://www.rfc-editor.org/info/rfc1924/. It took me quite some time to figure out that RFC was submitted in jest as an April fool's joke.
Regards,
Sjoerd Langkemper
Hi Sjoerd,
Thanks for the remarks and the suggestions. Currently, Tim who has already
started working on the implementation is busy on PHP8.6 release. So I
prefer we differ implementation details after the release of PHP8.6 to let
him concentrate on that first. As for the rest I have taken notes and will
follow up with some adjustments in the RFC if needed.
Regards,
Ignace
On Mon, Aug 10, 2026 at 12:28 PM Sjoerd Langkemper sjoerd-php@linuxonly.nl
wrote:
Hello Ignace, list,
About the encoding API RFC: https://wiki.php.net/rfc/data_encoding_api
I think this API can have a positive impact of security of PHP
applications:
- the current base64_decode is very tolerant towards invalid input,
causing both functional and security problems:
https://github.com/php/php-src/issues/20187- the proposed base58 and URL-safe base64 encode make it easier to
create secure tokens that are easy to use.The RFC contains several errors in its examples. For example in the
base16 encoding, $encodedWithSpaces contains "2c", a comma, but the
decoded string does not contain a comma. I did my best to correct these
issues in this repository:
https://github.com/Sjord/php-encoding-rfc-examplesOne of the examples calls base85_decode with DecodingMode::Forgiving.
However, the signature of the base85_decode function (under "The following
Base85 functions are added") does not have this parameter. Should it have
this parameter?The RFC proposes an option to choose a constant-time implementation. I am
not sure whether this is a good idea. Constant-time algorithms are pretty
difficult to develop and maintain. The benefit is questionable: for these
types of timing attacks, the attacker needs to be able to run code on the
same CPU as the victim application, which is not really common in how PHP
is used. If we would support this, I think it would be better to forward it
internally to libsodium or openssl, instead of developing this within PHP.LLMs and I have created an implementation here:
https://github.com/php/php-src/pull/23195. This was meant to experiment
with the API and try out the RFC, and not necessarily as the actual
implementation that gets finalized and merged.For a while I also considered whether to support the base85 algorithm
specified in RFC 1924 https://www.rfc-editor.org/info/rfc1924/. It took
me quite some time to figure out that RFC was submitted in jest as an April
fool's joke.Regards,
Sjoerd Langkemper