Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98640
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: <CAGa2bXbUYDgJxmmZfuS5ZbWCLjq0QPpDioM-zkU9j7EHA-D_ag@mail.gmail.com>
References: <CAGa2bXbUYDgJxmmZfuS5ZbWCLjq0QPpDioM-zkU9j7EHA-D_ag@mail.gmail.com>
Date: Mon, 27 Mar 2017 08:08:39 +0900
Message-ID: <CAGa2bXZ9_DtktnGpX38DHUvEzU4=9wMc_23fKxudzZWZ49A+Hw@mail.gmail.com>
To: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11490c2a08cdad054baa5105
Subject: Re: [RFC][VOTE] Improve hash_hkdf() parameter
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11490c2a08cdad054baa5105
Content-Type: text/plain; charset=UTF-8

Hi all,

On Sun, Mar 26, 2017 at 7:29 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:

> I suggest you to disclose the reason why against this change.
> Otherwise, you may be considered you don't understand crypto basic.
> i.e. HKDF(IKM) security depends on PRK being secure. To make PRK
> secure or more secure, "salt" parameter is required. "length" is
> irrelevant
> for security.
>

I'll try to explain a bit more by examples.

HKDF is designed to obtain the best possible "cryptographically strong
hash value" (key) for various key derivation operations. Current signature
could lead to insecure/wrong usages. (We have similar experience with
our PHP functions. e.g. uniqid, crypt, etc)


Example #1 : Deriving strong 256 bit AES key from 128 bit AES key.

$new_key = hash_hkdf('sha256', $AES_128bit_key, 32); // Derive 256 bit AES
key from 128 bit key
// No additional entropy, thus $new_key is not strong 256 bit AES key.
// Far from the best possible.

Users must not do this with HKDF. The same $new_key quality can
be obtained by simple SHA-256 hashing which is faster. Without
"strong derivation key", HKDF is not useful at all. The optimal way is

$new_key = hash_hkdf('sha256', $AES_128bit_key, 0, '',
$strong_derivation_key);
// where $strong_derivation_key = random_bytes(32); or like.



Example #2 : Deriving strong key from week key such as user entered password

$new_key = hash_hkdf('sha256', 'p@ssword');
// Almost the same as hash('sha256', 'p@ssword'); All of us should know how
bad this is.
// Far from the best possible.

Users must not do this with HKDF. The same could be done with simple hash().
Users must provide cryptographically strong derivation key, otherwise HKDF
is
useless.

$new_key = hash_hkdf('sha256', 'p@ssword', 0, '', $strong_derivation_key);
// where $strong_derivation_key = random_bytes(32); or like.
// Since input key material is weak, $strong_derivation_key must be secret


Example #3 : Deriving CSRF token from secret seed

$new_key = hash_hkdf('sha256', $secret_seed, 0, $version);
// Almost the same as hash('sha256', $secret_seed . $version);
// Far from the best possible.

Users must not do this with HKDF. The same could be done with simple hash().
Users must provide cryptographically strong derivation key, otherwise HKDF
is
useless.

$new_key = hash_hkdf('sha256', $secret_seed, 0, $version,
$strong_derivation_key);
// where $strong_derivation_key = random_bytes(32); or like.



There are looong lists of this kind of insecure/wrong usage with current
signature.

If you understand how to derive "strong key" by HKDF, you should realize
current hash_hkdf() function signature is far from the best.

Detailed rationale is explained the PHP RFC, but it seems many of us does
not
understand this. HKDF is supposed to derive "strong key", why should we
encourage "weak key" derivations with non optimal signature?

Regards,

P.S. I strongly objected the current signature before 7.1 merge. Shouldn't
committer write RFC before commit in the first place? Especially for
released versions.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11490c2a08cdad054baa5105--