Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98709
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <0285A0ED-A39F-46C9-A927-3C786F2B256D@koalephant.com>
References: <CAGa2bXbUYDgJxmmZfuS5ZbWCLjq0QPpDioM-zkU9j7EHA-D_ag@mail.gmail.com>
 <CAGa2bXZ9_DtktnGpX38DHUvEzU4=9wMc_23fKxudzZWZ49A+Hw@mail.gmail.com> <0285A0ED-A39F-46C9-A927-3C786F2B256D@koalephant.com>
Date: Sat, 1 Apr 2017 11:27:23 +0900
Message-ID: <CAGa2bXYFw6Uz9cLFM1QT9ULak9uJcM4mr0R59TEa0eYf-tAm+Q@mail.gmail.com>
To: Stephen Reay <php-lists@koalephant.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11409c16fa9438054c11acf2
Subject: Re: [PHP-DEV] [RFC][VOTE] Improve hash_hkdf() parameter
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11409c16fa9438054c11acf2
Content-Type: text/plain; charset=UTF-8

Hi Stephen,

On Mon, Mar 27, 2017 at 1:09 PM, Stephen Reay <php-lists@koalephant.com>
wrote:

>
> It sounds to me like it is *possible* to currently use hash_hkdf() in a
> secure manner, but that you (and some others?) feel the arg order and
> default args are not conducive to safe/secure usage.
>

It's _possible_, of course. Problem is _new_ function has
 - insecure signature (it ignores strong RFC 5689 recommendation)
 - inconsistent signature and return value (hash() and hash_hmac())
 - no major use(application) for PHP apps (Length has almost no use with
PHP apps)

If users would like to generate arbitrary length hash from existing hash
value with _insecure_ way, they should
use new SHA-3 standards, i.e. SHA-3 already has 2 SHAKE algorithms that
generate arbitrary length hash value,
SHAKE128(M, d) and SHAKE256(M, d).
No reason to encourage less secure HKDF usage to obtain arbitrary length
hash value.

Current hash_hkdf() signature does not make much sense with regard to
cryptographically, consistency and
expected usage.

Given that the function is live in the wild, massively changing the order
> of things and defaults is an instant red flag for myself, and I believe a
> lot of other people.
>

Aside from it should not be merged into PHP 7.1 in the first place.
There are only 2 (or 3) bug fix versions released. Fixing mistake ASAP is
better. IMHO.


To me this sounds more like an issue that could be relatively quickly
> improved by a documentation update that highlights how to securely use the
> function.
>

While documentation may work, it seems silly for me to write,

  Even if "salt" is the last optional parameter, users must set appropriate
"salt" whenever it is possible for maximum key security.

for new function.

Yes, if there are more secure defaults that would be nice, but that ship
> has sailed, and the function was on it.


Thank you for your comment.
I would like to try to fix it at least.

To avoid this kind of confusions, we are better to have RFC if there is
strong objection.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11409c16fa9438054c11acf2--