Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:81024
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.45 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <CAPKwhws-TLdo2_QUwunn6cGZg4sotHKooJboTSqONULGBasbyQ@mail.gmail.com>
References: <CAPKwhws-TLdo2_QUwunn6cGZg4sotHKooJboTSqONULGBasbyQ@mail.gmail.com>
Date: Fri, 23 Jan 2015 15:06:20 +0900
Message-ID: <CAGa2bXYBLbObW401Lc50zY39xh8eNqGzkVhoSbdizfGh5svy7g@mail.gmail.com>
To: Scott Arciszewski <scott@arciszewski.me>
Cc: "inter >> PHP internals" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a304ed3b9d8050d4b981e
Subject: Re: [PHP-DEV] Identify timing-safe function candidates
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113a304ed3b9d8050d4b981e
Content-Type: text/plain; charset=UTF-8

Hi all and Scott,

This mail is for all mostly.

On Fri, Jan 23, 2015 at 10:37 AM, Scott Arciszewski <scott@arciszewski.me>
wrote:

> As per the conversation on this Pull Request
> https://github.com/php/php-src/pull/909#issuecomment-71077928
>
> What functions are involved in real world PHP applications (frameworks,
> popular CMSes, etc) that operate on encoded encryption keys that might
> benefit from having a timing-safe implementation?
>
> So far, I can identify:
>
> - bin2hex()
> - hex2bin()
> - base64_encode()
> - base64_decode()
> - json_encode()
> - json_decode()
> - parse_ini_file()
>
> I think it would be great to compile a master list of which functions are
> commonly used to store long-term encryption keys (random bytes that could
> cause parse errors).
>
> Also, would it be better to use a prefix (e.g. ts_*), a class with static
> methods (e.g. TimingSafe::bin2hex()), or functions in a namespace (e.g.
> \TimingSafe\bin2hex())?
>

To perform timing based attacks based on conversion functions, attacker
must
be able to get correct secret timing for statistical analysis.
(I'm assuming key comparison is constant. PHP user must use hash_equals()
to achieve this)

This situation may seem unlikely, but attacker can observe HTTPS
request/response
time (i.e. wiretap) and guess which one is the request that has secret.
(request size is useful for this, for example.) Then attacker sends guessed
secret
to server. Attacker may analyze guessed secret candidates locally since
algorithm is known to attacker. It's better guess than without clue.

Users may eliminate the risk by not having conversion at all or mitigate
the risk by
having large random variable length secret, I suppose. (Please correct me
if I'm wrong)

- bin2hex()
- hex2bin()
- base64_encode()
- base64_decode()
- json_encode()
- json_decode()

These are candidates to be timing safe. mb_convert_encoding() may be
used to base64 encode/decode, so it's a candidate also. There are others
like uu encode,
url encode, etc.

- parse_ini_file()

I'm not sure if it is vulnerable. Aren't values copied simply? (i.e.
constant time)
It may not be timing safe due to parse.

There are many conversion functions, some of them are complex. Why don't we
make time safe bin2hex/hex2bin only and advocate users to use them for
secret
data conversion? All of these are better to be timing safe, but it is not
feasible, is it?

Please note that we need timing safe binary to text/text to binary
conversion function
for better security because crypto algorithm like AES has binary key. If
text is used,
it reduces effective bits unnecessary.

BTW, compression can help guessing secrets (even worse). It also should be
noted somewhere.


>
> Scott
>
> P.S. At this point, I'm also withdrawing my participation of this
> discussion. If you don't think it's worthwhile to fix this, that's your
> decision. I've had some major life events happen and I no longer have time
> to debate this. Thanks for understanding.
>

That's too bad.
Thank you for the timing safe bin2hex patch.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113a304ed3b9d8050d4b981e--