Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91874 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 71132 invoked from network); 22 Mar 2016 23:11:20 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 22 Mar 2016 23:11:20 -0000 X-Host-Fingerprint: 90.205.35.47 unknown Received: from [90.205.35.47] ([90.205.35.47:19273] helo=localhost.localdomain) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 91/57-30596-711D1F65 for ; Tue, 22 Mar 2016 18:11:19 -0500 Message-ID: <91.57.30596.711D1F65@pb1.pair.com> To: internals@lists.php.net References: Date: Tue, 22 Mar 2016 23:11:16 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0 SeaMonkey/2.40 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Posted-By: 90.205.35.47 Subject: Re: [RFC] RFC4648 encoding From: ajf@ajf.me (Andrea Faulds) 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/