Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91966
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain paragonie.com designates 209.85.218.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <105488689.506.427e4c07-ed66-4bbb-aea2-097c92d2538e.open-xchange@myra232.schumann.net>
References: <CAKws9z1bY=nLo=K8D9OQ_K0yhfNE-5SAEaDgyZnM34P3v8im9g@mail.gmail.com>
	<56F7398A.5050002@gmail.com>
	<105488689.506.427e4c07-ed66-4bbb-aea2-097c92d2538e.open-xchange@myra232.schumann.net>
Date: Sat, 26 Mar 2016 22:04:22 -0400
Message-ID: <CAKws9z0d+-Gs2iF5wEB1d_1H_156LgQYoA1xvFMC7RnPT-kSRw@mail.gmail.com>
To: Sascha Schumann <sascha.schumann@myrasecurity.com>
Cc: Stanislav Malyshev <smalyshev@gmail.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113dc710f53943052efe3679
Subject: Re: [PHP-DEV] [RFC] RFC4648 encoding
From: scott@paragonie.com (Scott Arciszewski)

--001a113dc710f53943052efe3679
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Sat, Mar 26, 2016 at 9:55 PM, Sascha Schumann <
sascha.schumann@myrasecurity.com> 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.
> >
> > What's the use case for it? Is anybody using base32 now?
>
> I'd have a few times if the functionality had been easily available.
> =E2=80=8B=E2=80=8B
>
> Please make this a single call:
>
> str_convert_base($in, $old_base, $new_base);
>
> "str_" because it applies in most cases to stuff not representable as a P=
HP
> float/int.
>
> > > 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-ter=
m
> =E2=80=8B=E2=80=8B
>
> As this requires slowing things down, this should be an extra, optional
> feature.
> Either to the relevant functions, or more likely globally, as it does not
> make
> much sense on a per-function level.
>
> Sascha
>

=E2=80=8BHi Sascha,
=E2=80=8B

Please make this a single call:
> str_convert_base($in, $old_base, $new_base);
> "str_" because it applies in most cases to stuff not representable as a P=
HP
> float/int.


T=E2=80=8Bhat would be ill-advised. What I'm proposing is to cover RFC 4648=
.

https://tools.ietf.org/html/rfc4648

These are specific base-{2^n} encoding schemes that are easy to implement
in constant time. An arbitrary change-of-base function just _begs_ people
to port Base62 or Base58 which is much more difficult to reason about when
it comes to timing safety.

Also: We already have base_convert(). If you'd like to write a wholly
separate RFC to make a function cover bases > 36, that might be useful.

I'm specifically focusing on the "let's prevent cache-timing leaks when
people encode-then-store/load-then-decode cryptographic secrets in PHP"
problem here.
=E2=80=8B

As this requires slowing things down, this should be an extra, optional
> feature.
> Either to the relevant functions, or more likely globally, as it does not
> make
> much sense on a per-function level.


That's something to consider, but please keep in mind a sense of
perspective: Anthony measured a _negligible_ performance hit (5 * 10^-6
seconds).

Are there any real-world applications that would suffer tremendously from
this academic slow-down?

If so, we should discuss how to proceed.

If not, we might want to consider disregarding the penalty entirely.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com/>

--001a113dc710f53943052efe3679--