Hi Scott,
Scott Arciszewski wrote:
PHP already offers bin2hex()/hex2bin() and base64_encode()/base64_decode().
This covers part, but not all, of RFC 4648.
I'd like to extend the coverage to include, at minimum, Base32.
Sounds good. It fills a gap and would doubtless be useful for some
applications.
This made me wonder if we should add a generalised arbitrary-base with
arbitrary character set pair of encoder and decoder functions. But
that's a niche use case, they're simple enough to do in userland.
I'd also like to make these functions to be written to resist cache-timing
attacks (i.e. when used to encode/decode encryption keys for long-term
storage). Userland PoC: https://github.com/paragonie/constant_time_encoding
http://blog.ircmaxell.com/2014/11/its-all-about-time.html
These modifications can either be made in-place (at a negligble cost on the
scale of nanoseconds) or they can be an alternative implementation. i.e.
* bin2hex_ts()
* base64_encode_ts()
* base32_encode_ts()
Unless there's a huge, and actually problematic, performance difference,
then I'd suggest we replace our existing implementations, rather than
adding new functions. This way existing code potentially benefits from
the security improvement, we don't give developers an unncessary choice,
and there's no extra clutter.
One more thing, only vaguely on-topic: the base64_decode/_encode
functions don't let you specify whether you want "base64" or the variant
"base64url", they always use the former. You can use a regular
expression or strtr() to convert the input/output, of course, but it
would be more efficient (and perhaps for security purposes, less likely
to allow timing attacks?) if there was built-in support. So, should we
add a parameter to these functions to specify if the base64url variant
is to be used?
Thanks for your proposal!
--
Andrea Faulds
https://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
