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

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