[PHP-DEV] Re: [RFC][DISCUSSION] Add RFC 4648 compliant data encoding API

ignace nyamagana butera <[email protected]>
Newsgroups gmane.comp.php.devel
Message-ID <CAOV5rgbc87KOD-VmDJkg_M00phzOoFYwWSm3e8=h4Cku7QUExg@mail.gmail.com>
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 <[email protected]>
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:
>
>    1. the current base64_decode is very tolerant towards invalid input,
>    causing both functional and security problems:
>    https://github.com/php/php-src/issues/20187
>    2. 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
>
>
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.