Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.43 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGa2bXbrX8P7tV06FTprskzn-o7C36U=6ZBW70umL-ZLfV6NfQ@mail.gmail.com>
References: <CAGa2bXbrX8P7tV06FTprskzn-o7C36U=6ZBW70umL-ZLfV6NfQ@mail.gmail.com>
Date: Sat, 25 Mar 2017 12:17:13 +0100
Message-ID: <CAF+90c-v5zK-iXd80E4iAGut5ni4kLd_Lq1mE_d0RFeTZGewKA@mail.gmail.com>
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Andrey Andreev <narf@devilix.net>
Content-Type: multipart/alternative; boundary=001a11471934835a39054b8c4071
Subject: Re: [PHP-DEV] [RFC] [VOTE] Improve hash_hkdf() parameter
From: nikita.ppv@gmail.com (Nikita Popov)

--001a11471934835a39054b8c4071
Content-Type: text/plain; charset=UTF-8

On Sat, Mar 25, 2017 at 3:25 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> Hi all,
>
> Since hash_hkdf() is in PHP 7.1.2, I start vote from today.
>
> Current hash_hkdf() function signature does not make sense.
>
>  - hash_hkdf() is simple hash_hmac() extension, yet it has totally
>    different signature.
>  - Return value is binary unlike other hash functions.
>  - The signature is insecure.
>
> https://wiki.php.net/rfc/improve_hash_hkdf_parameter
>
> Current signature is overly optimized very limited crypto operation
> and cannot be optimal by above reasons.
>
> Fortunately, almost all users are not using current hash_hkdf().
> It's only from 7.1.2 to 7.1.4 now. We should avoid yet another
> new inconsistent and insecure function. It would be better to be
> fixed ASAP, IMHO.
>
> Vote start: 2017-03-25
> Vote end: 2017-04-06 UTC 23:59:59
>

Voting against this because it introduces a BC break on a stable branch in
a point release. Of course I also disagree with the proposed change itself,
but this has already been extensively discussed in previous threads, and I
believe the BC break is sufficient grounds for rejection on its own.

I cannot, however, entirely refrain from pointing out the irony of making
all parameters but $length required, while $length is actually the one
parameter that any reasonable use of this function must specify: otherwise
you would depend on the digest size of the hash function magically
coinciding with the key length of your cipher (for example).

Nikita

--001a11471934835a39054b8c4071--