Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:98269
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: <CAKws9z3oOuPjLutsYNfOVToMMZTfKK_o5FEpVLr6PNKyQ3YXBg@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> <CAKws9z3oOuPjLutsYNfOVToMMZTfKK_o5FEpVLr6PNKyQ3YXBg@mail.gmail.com>
Date: Thu, 9 Feb 2017 16:07:00 +0900
Message-ID: <CAGa2bXa-cxxOqB__E17QTA4czp-PsaqT5DaWBm=F_+=x=QLzCw@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>
Cc: Andrey Andreev <narf@devilix.net>, "internals@lists.php.net" <internals@lists.php.net>, 
	Nikita Popov <nikita.ppv@gmail.com>
Content-Type: multipart/alternative; boundary=001a114a8a5c1615f1054813a389
Subject: Re: [PHP-DEV] hash_hkdf() signature
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a114a8a5c1615f1054813a389
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi all and Scott,

On Wed, Feb 8, 2017 at 11:22 PM, Scott Arciszewski <scott@paragonie.com>
wrote:

> On Wed, Feb 8, 2017 at 6:27 AM, Andrey Andreev <narf@devilix.net> wrote:
>
>> Hi,
>>
>> 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 enou=
gh
>>> of a downside to dismiss an argument for better security? Maybe.
>>>
>>>
>> I said this in another thread already, but I'll re-iterate here ... Usin=
g
>> 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.
>>
>> - 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, you'd also know what to do with Salt.
>> - 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.
>>
>> One could use Salt for the purposes of Info, but that would be misusing
>> the algorithm.
>> Over-focusing on Section 3.1 of the specification, while at the same tim=
e
>> ignoring Section 3.2 - arbitrarily making OptionalParamX mandatory becau=
se
>> the note about it mentions the word "security". Noble, but misguided.
>>
>> I'd have no problem if ALL of the params were made non-optional - I'm al=
l
>> for that, but either do that or leave it untouched.
>>
>> * RFC 5869: https://tools.ietf.org/html/rfc5869
>>
>> Cheers,
>> Andrey.
>>
>
>
> Given everything discussed in this sub-thread so far, =E2=80=8BI would be=
 in favor
> of making everything non-optional.
>

I'm OK with making 'salt' and 'info' required. Users should
consider 'info'(key context) could be used almost always before
omitting it.

I suppose most developers will use 'length' for shorter length.
i.e. Weaker output keys. If it's not too short, shorter key length works.
I'm not sure if shorter output key length, that would weaken the key,
does any good in general .
Note: longer output key does not make output key stronger. It may
hide used hash function, though.

Most use cases would be AWS S3 pre-signed URL like
usage that users do not have to care long keys. With such
use cases, users are better to use key as is. i.e. Use default
hash output length.

There may be vote option for length, but I'm in favor of leave
it as optional. I do care about parameter order, but what to be
required is not too much concern to me.

Regards,

BTW, I don't think of typical PHP application that requires
human typable short password with HKDF. What kind of
application would be? Thank you.

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a114a8a5c1615f1054813a389--