This proposal was rejected.
6 months has not passed since it was rejected.
There will be no vote on these proposals in the near future.
Please stop.
Joe
On Tue, Sep 12, 2017 at 3:52 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
> Hi all,
>
> hash_hkdf() discussion was mess, but it came to conclusion finally a while
> ago.
> Apparently, there are confused readers still. I discovered it in other
> thread.
> I would like to make it clear again what's wrong in the discussion.
> If you think I was wrong about HKDF, you should read this.
>
>
> Nikita and Adnrey's Opinion:
> 1. Keys("IKM") must be strong always
> (with very limited exception? Usage example is not disclosed)
> 2. From 1, "Salt" is pure optional parameter
> 3. HKDF is designed for specific purpose
> (crypto keys only? I suppose)
>
> Therefore, "Salt" is the last optional parameter and hash_hkdf() returns
> BINARY.
>
>
> I assume Andrey realized his misunderstanding finally and would not repeat
> this ridiculous discussion. Andrey, you should realize when you couldn't
> show
> us any valid usage example. However, I appreciate discussion because I
> couldn't
> find out where you misunderstood exactly and why you insisted above
> without
> discussion.
>
> Anyway, their statements make none of sense with HKDF specifications.
> It is easy to accuse "You are wrong" or "You don't understand" regardless
> of
> validity. It requires a lot of work to make it clear what's really
> correct/incorrect.
> Those who are still do not understand what the HKDF RFC is about, please
> read carefully what the RFC states.
>
>
>
> What HKDF RFC says:
>
> The algorithm: https://tools.ietf.org/html/rfc5869#section-2.2
> ----
> HKDF-Extract(salt, IKM) -> PRK
> PRK = HMAC-Hash(salt, IKM)
> ----
> From this algorithm alone, HKDF is clearly expecting weak keys("IKM").
> i.e. Remember how hash_hmac() works.
>
>
> About "Salt": https://tools.ietf.org/html/rfc5869#section-3.1
> ----
> HKDF is defined to operate with and without random salt. This is
> done to accommodate applications where a salt value is not available.
> We stress, however, that the use of salt adds significantly to the
> strength of HKDF, ensuring independence between different uses of the
> hash function, supporting "source-independent" extraction, and
> strengthening the analytical results that back the HKDF design.
> ----
> It is clear that salt is made optional only for apps that cannot use salt.
> It is clear that HKDF recommends "Salt" regardless of key("IKM") strength.
> "Salt" is required for "source-independent" extraction. i.e. Make IKM
> entropy/strength irrelevant and derived key stronger.
>
>
> Omitting "Salt": https://tools.ietf.org/html/rfc5869#section-3.3
> ----
> In some applications, the input key material IKM may already be
> present as a cryptographically strong key. In this case, one can skip
> the
> extract part and use IKM directly to key HMAC in the expand step.
> ----
> It says "Salt" may be omitted __only when__ keys("IKM") are strong already.
> In other words, "Salt" is mandatory for not cryptographically strong
> keys("IKM").
>
> e.g. $rsa256key = hash_hkdf("sha256", $rsa128key) is misuse, _NOT_ textbook
> HKDF usage example as Nikita mentioned.
> hash_hkdf("sha256", $rsa128key, 0, '', $random256salt) is correct/designed
> usage.
>
>
>
> Reason Why Nikita and Andrey misunderstood the RFC:
>
> They ignored previously explained descriptions and cherry picked irrelevant
> statements in the RFC.
>
> Application of HKDF: https://tools.ietf.org/html/rfc5869#section-4
> -----
> On the other hand, it is anticipated that some applications will not
> be able to use HKDF "as-is" due to specific operational requirements,
> or will be able to use it but without the full benefits of the
> scheme. One significant example is the derivation of cryptographic
> keys from a source of low entropy, such as a user's password. The
> extract step in HKDF can concentrate existing entropy but cannot
> amplify entropy. In the case of password-based KDFs, a main goal is
> to slow down dictionary attacks using two ingredients: a salt value,
> and the intentional slowing of the key derivation computation. HKDF
> naturally accommodates the use of salt; however, a slowing down
> mechanism is not part of this specification.
> -----
>
> Especially this part
>
> -----
> the derivation of cryptographic
> keys from a source of low entropy, such as a user's password. The
> extract step in HKDF can concentrate existing entropy but cannot
> amplify entropy.
> -----
>
> It says HKDF cannot be used with low entropy/weak keys("IKM"). This
> supports
> their opinion.
>
> However, these are explanations for __"Invalid/Wrong HKDF usage"__ as
> "Password
> hashing like PBKDF2". These are __irrelevant__ for "Valid/Correct HKDF
> usage" at
> all. i.e. This basically says "Hey, you shouldn't use HKDF for password
> hashing "as-is".
> HKDF is not password hashing that requires stretching.".
>
> Key derivation and password hashing is fundamentally different operation
> because "Salt" in password hashing is _non secret_ always by design.
> Password hashing requires entropy amplification(stretching), but key
> derivation does not require amplification by HMAC/cryptographic hash
> characteristics.
>
> Even with weakest password, password(IKM) is protected and OKM is secure
> because HKDF's "Salt" is designed to be "secret" or "non secret" as
> explicitly
> described in the RFC. Secret salt makes keys are secured. This is obvious
> from the algorithm, i.e. Remember how hash_hmac() works again.
>
>
> Lastly,
> Application of HKDF: https://tools.ietf.org/html/rfc5869#section-4
> states in the first sentence.
> -----
> HKDF is intended for use in a wide variety of KDF applications.
> -----
> It is obvious that HKDF is general purpose KDF. The RFC even explains
> non KDF usage as CSPRNG.
>
>
>
> My Comments:
> From the algorithm alone, it is very clear to me that HKDF is expecting
> weak keys, and
> salt is used for additional entropy/complexity for key security, and salt
> should be used
> always.
>
> It was very difficult for me to understand what Nikita and Andrey were
> insisting and
> referring, because their discussion was very confusing and makes none of
> sense
> with HKDF RFC.(and HMAC, crypto hash characteristics)
>
> Current API
> - encourages insecure misuse, "Salt" is mandatory always with the
> exception
> when salt cannot be used.
> - extremely insecure, weak keys are vulnerable without "secret Salt"
> i.e. Who would use hash_hmac() without keys?
>
> In addition, it has completely unnecessary API inconsistency with respect
> to other
> hash functions.
>
> Nikita and Andrey, don't you have something to say about this mess, do you?
>
> IMO, you should ask to the list by yourself so that your ridiculous
> hash_hkdf() API
> will not be kept forever because of your misunderstanding. If I were you, I
> would
> not leave behind such shameful API that would be laughed at by everyone.
>
> RMs, if I were you, I will consider fixing the API seriously. Promoting
> insecure
> _key_ derivations forever is nonsense.
>
> This would be the last post for this issue, unless there are people who
> still don't
> understand what HKDF is.
>
> Regards,
>
> P.S.
> No one really read the internet RFC, this is another issue...
> Session security and input data security discussion have similar pattern.
> I insists based on standards and/or guidelines, others just ignore
> standards/guidelines/security because they don't use/are not familiar with
> them.
> If it is simply a matter of preference, it would be acceptable. However,
> in case of security related issues, this is not a healty technical
> discussion
> at all.
>
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>
> On Wed, Sep 6, 2017 at 10:15 AM, Yasuo Ohgaki <yohg...@ohgaki.net> wrote:
>
> > Hi all,
> >
> > This is the last recommendation for hash_hkdf[1]. In fact,
> > this would be the last chance to fix because we'll have 7.2 soon.
> > The issue is secure usage and API consistency.
> >
> > Currently hash_hkdf() has following signature:
> >
> > <binary string> hash_hkdf(string $algo , string $ikm [, int $length = 0
> [,
> > string $info = '' [, string $salt = '' ]]] )
> >
> > These are rationals behind recommendation. There are many, but
> > please read on.
> >
> > === Parameter Order ===
> >
> > HKDF[2] algorithm is:
> > 1. General purpose key derivation function as per RFC 5869
> > 2. "$salt" parameter is a "pre-shared _KEY_" in many cases as mentioned
> > RFC 5869
> > 3. "$salt" (or preshared key) is very strongly recommended for security
> > season as per RFC 5869
> > 4. Supplying salt that the same length of input key does not affect
> > performance as per RFC 5969
> > 5. "$info" is what makes HKDF useful, but it's less important as
> > described in RFC 5869
> > 6. "$length" is truly an optional parameter for very specific encryption
> > algorithm or usage.
> >
> > Rationale for change:
> > 1. Key derivations without secondary key ($salt) does not make sense
> when
> > secondary key could be available. HKDF is designed for best possible
> > key
> > security with the key. Not using secondary key ($salt) simply
> > downgrades
> > key security without no reason. i.e. HKDF performance is the same
> > when $salt has the same as hash is set.
> > 2. HKDF is based on HMAC. When $info has no use, HMAC would be the best
> > choice for it. i.e. $newkey = hash_hmac($ikm, $key);
> > 3. It does not make sense violating RFC recommendations for a RFC
> > implementation.
> >
> > From these facts and reasons, $salt, $info and $length parameter order
> and
> > requirement should be changed from
> >
> > string $algo , string $ikm [, int $length = 0 [, string $info = '' [,
> > string $salt = '' ]]]
> >
> > to
> >
> > string $algo , string $ikm , string $salt, string $info = '' [,
> > int $length = 0 ]
> > Note: Users can set empty string if they really don't need $salt and/or
> > $info.
> >
> > Conclusion:
> > This way, users would have better chances to use hash_hkdf() more
> securely
> > and
> > properly.
> >
> > [1] http://php.net/hash_hkdf
> > [2] http://www.faqs.org/rfcs/rfc5869.html
> >
> > === Return Value and Output Option ===
> >
> > The most common HKDF usage with PHP would be:
> > 1. CSRF token generation that is specific to a request with expiration
> > time.
> > (HEX return value would be appropriate, not BINARY)
> > 2. API access token generation that does not transmit "The API Key", but
> > derived key by HKDF. It also should have expiration time.
> > (HEX return value would be appropriate, not BINARY)
> >
> > Consistency with other hash_*() functions:
> > 1. All of other hash_*() returns HEX string hash value.
> > 2. hash_hkdf() is the only one returns BINARY hash value.
> >
> > Conclusion:
> > hash_hkdf() should return HEX by default, not BINARY.
> > Optional [, bool $raw_output = false ] should be added just like other
> > hash_*().
> >
> >
> > === Compatibility ===
> >
> > IMHO, current hash_hkdf() should not be added by PHP 7.1.2, but 7.2.0
> > in the first place. The mess could be resolved by 7.2.
> >
> > Anyway, hash_hkdf() is added 7.1.2. Hopefully not many users are
> > using it yet. If we change API with 7.2 release, there would be least
> > possible confusions. (We may remove it from 7.1 to avoid confusions, too)
> >
> > Our choices:
> > - Keep the current insecure/inconsistent API forever.
> > - Change the API to have secure/consistent API forever.
> >
> > Conclusion:
> > No conclusion for this. There would be conflicting options.
> >
> >
> > I strongly think it is not worth to keep this insecure/inconsistent API
> > forever.
> > I prefer to change the API to what it should be.
> >
> > What should we do for this?
> > Comments?
> >
> >
> >
> > P.S.
> >
> > Nikita, you've said following during HKDF discussion:
> > - HKDF for CSRF tokens/etc does not make sense at all.
> > - Current parameter order and return value makes perfect sense
> > and has valid/common usages.
> > - Everyone one this list, shouldn't listen to me because I'm insane and
> > totally misunderstood what the HKDF is.
> >
> > Phrases are not the exact, but it should be correct enough. Some part
> > is my fault, w/o reading mail and/or poor English. I blindly assumed
> > you've understand RFC 5869 and possible common usages with PHP. I
> > apologized for the confusion and tried to explain why w/o success.
> >
> > If you still believe what you've said is correct, I don't request you to
> > take these back, show us at least one common/reasonable hash_hkdf()
> > usage example for current API, and point out what's wrong my
> > recommendations
> > and rationales above.
> >
> > If not, I request you to take it back. I respect your contributions much,
> > but
> > the last one you've said is out of tolerance.
> >
> > --
> > Yasuo Ohgaki
> > yohg...@ohgaki.net
> >
> >
>
