On Tue, Mar 22, 2016 at 7:11 PM, Andrea Faulds <a...@ajf.me> wrote: > 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 > >
Hi Andrea, The performance impact should be negligible; ircmaxell found a difference of 5 microseconds. Re: Base64url, that was another question I'd been pondering. My PoC, based on the work of Sc00bz, covers all of RFC 4648. That includes base32hex and base64urlsafe. Do we want to cover those as well? I've noticed a lot of projects using a url-safe variant, so there may be popular demand for it. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>
