Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91875
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.214.178 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <91.57.30596.711D1F65@pb1.pair.com>
References: <CAKws9z1bY=nLo=K8D9OQ_K0yhfNE-5SAEaDgyZnM34P3v8im9g@mail.gmail.com>
	<91.57.30596.711D1F65@pb1.pair.com>
Date: Tue, 22 Mar 2016 19:40:07 -0400
Message-ID: <CAKws9z2gDH=d5_joEs5diNra=j_r3BsRjm3xJQ-MgOvZqFXwAQ@mail.gmail.com>
To: Andrea Faulds <ajf@ajf.me>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136a210bcc7fc052eabbb16
Subject: Re: [PHP-DEV] Re: [RFC] RFC4648 encoding
From: scott@paragonie.com (Scott Arciszewski)

--001a1136a210bcc7fc052eabbb16
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Mar 22, 2016 at 7:11 PM, Andrea Faulds <ajf@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-timin=
g
>> 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 th=
e
> 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 function=
s
> 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() t=
o
> 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
>
>

=E2=80=8BHi Andrea,

=E2=80=8BThe performance impact should be negligible; ircmaxell found a dif=
ference
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/>=E2=80=8B

--001a1136a210bcc7fc052eabbb16--