Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98268
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: <CAPhkiZzO_B5OZExTYGpwk1oBEb=J4Mvw3DYJznU3+etwSuxqsw@mail.gmail.com>
References: <CAGa2bXZWKqJpvWma1zdY8j+yFg-pMXBZZHpUHb=KhJQucCf+9Q@mail.gmail.com>
 <CAKws9z31kvAs16kU1QBfdTP+G0d21PYcRaCw2-8rdsZpsRxkFg@mail.gmail.com> <CAPhkiZzO_B5OZExTYGpwk1oBEb=J4Mvw3DYJznU3+etwSuxqsw@mail.gmail.com>
Date: Thu, 9 Feb 2017 14:34:42 +0900
Message-ID: <CAGa2bXYwixVM87nX21pQfxNXTZ=UN7Euzv7yKhRQUTYu1vJnfQ@mail.gmail.com>
To: Andrey Andreev <narf@devilix.net>
Cc: Scott Arciszewski <scott@paragonie.com>, 
	"internals@lists.php.net" <internals@lists.php.net>, Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a11432912fc05540548125838
Subject: Re: [PHP-DEV] hash_hkdf() signature
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a11432912fc05540548125838
Content-Type: text/plain; charset=UTF-8

Hi Andrey,

On Wed, Feb 8, 2017 at 8:27 PM, Andrey Andreev <narf@devilix.net> wrote:

> On Tue, Feb 7, 2017 at 10:22 PM, Scott Arciszewski <scott@paragonie.com>
> wrote:
>
>>
>>
>> Although the RFC itself says that salts are optional, the argument to
>> make them required in PHP's implementation has merit. The only downside is:
>> If you're integrating with an implementation that doesn't require salts,
>> and the application doesn't use salts, you're out of luck. Is that enough
>> of a downside to dismiss an argument for better security? Maybe.
>>
>>
> I said this in another thread already, but I'll re-iterate here ... Using
> a salt should be recommended, but the suggestion here takes that out of
> context and misses a key point - that the Length and Info params are not of
> any less importance overall.
>

From the HKDF algorithm, importance is clear. Salt >>> info > length.

Salt is the most important to secure input key. You seem to think following
is the most important.

 - Salt could be optional _only_ when input key is cryptographically strong.

What this means is

 - Salt is absolute _mandatory_ parameter unless input key is
absolutely strong key.

- Length is effectively the key size and is in fact not optional in
> RFC5869*. You have to really know what you're doing if you don't use it,
> and choose the hash function very carefully. I'd argue that if you know
> this well enough,
>
- Info is technically optional, but pretty much the feature why you'd
> choose HKDF over other KDFs. It's what makes HKDF's more useful in that it
> enables derivation of multiple OKMs from a single IKM. If you don't need
> Info, chances are you don't need HKDF.
>

There is huge difference between "Required to be implemented" and
"Required/important as parameter".
Implementation requirement is _nothing_ to do with parameter
requirement/importance.

'salt' could be omitted the application that input key is always strong.
This cannot be applied to
generic API like hash_hkdf() that would be used by countless applications.

Why you recommends following usage?
hash_hkdf('sha256', $weak_ikm, 9); // We can generate strong key easily,
Nice! <= Must not do this.

One could use Salt for the purposes of Info, but that would be misusing the
> algorithm.
>

I totally agree.
HKDF is specific about 'salt' and 'info' task. Salt is entropy to make
input/output
key strong/stronger. Info is for output key context.

Over-focusing on Section 3.1 of the specification, while at the same time
> ignoring Section 3.2 - arbitrarily making OptionalParamX mandatory because
> the note about it mentions the word "security". Noble, but misguided.
>

What's the reason why you trying to disregard RFC 5869 strongly recommends?

   "designers of applications are therefore encouraged to provide salt
values to
   HKDF if such values can be obtained by the application."

It seems you're mixed up with "Implementation requirement" and "Parameter
requirement/importance".
After all, we are implementing RFC 5869, why we should not follow
recommendation?


> I'd have no problem if ALL of the params were made non-optional - I'm all
> for that, but either do that or leave it untouched.
>
> * RFC 5869: https://tools.ietf.org/html/rfc5869
>

While I don't mind requiring both 'salt' and 'info', I strongly disagree
with the current parameter order and 'length' is pure optional parameter.
'info' is important but optional. 'salt' can only be optional when input
key
is absolutely cryptographically strong.

Parameter order must reflect
 - importance of the parameter
 - likelihood to be used

Salt is the most important for both input and output key security.
Salt is mandatory and/or can be used for almost always with PHP.
Salt usage results in better design/security.
Salt is often used as final key as combined key.

Does 'length' and/or 'info' achieve or designed for aboves? I don't think
so.

hash_hkdf() is generic API. $ikm cannot be strong key always.
Assuming $ikm to be strong is simply wrong assumption.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a11432912fc05540548125838--