Re: [PHP-DEV] hash_hkdf() signature and return value

[Yasuo Ohgaki]

Hi Dan,

Sorry for keep posting broken English.

I shouldn't difficult.
>

It shouldn't be difficult.

Looking forward more than handful, useful and common hash_hkdf()
application
examples for PHP that justify the API. If you would not like to spend time
for working
code, just ideas are OK also.

Regards,

Yasuo

Re: [PHP-DEV] hash_hkdf() signature and return value

[Yasuo Ohgaki]

Hi Dan,

I appreciate your feedback, regardless of your opinion towards this issue.

On Wed, Sep 6, 2017 at 8:04 PM, Dan Ackroyd  wrote:

> On 6 September 2017 at 02:15, Yasuo Ohgaki  wrote:
> > What should we do for this?
>
> Not us, you.
>

OK. It is recorded that you think current API is totally valid.
I'm not sure who is "us". Please reply and record your opinion.


>
> You should start listening to other people's feedback.
>
> You continually refuse to accept any feedback that doesn't agree with
> your world-view, not only on the subject of hkdf, but on validation
> and other things you think are "MANDATORY"
>

Well, my thoughts are not totally my inventions.

For HKDF, it came from the RFC 5689 basically.

For input validations, it is originated in Defensive Programming. Defensive
Programming is referred in early 90's AFAIK, it is called secure programming
or secure coding now. I believe the basic idea was developed 60's computer
scientists who researched program execution correctness verification
methods.

You should respect RFC votes and stop bringing up the same discussions
> over and over again. This is incredibly tedious.
>

Did you really read the RFC 5689?
Please mention what is wrong with my statements if you think my statements
are totally wrong.  It should be easy to point it out, since I provided
many points.
This is technical list, not political list nor religious list after all.

I should note that no valid code example was presented that justifies
current API.

Not a single valid code example, yet.

This fact infers what you say "us" have concrete reason(s) that supports
current API validity.

Please provide undisclosed valid code example that would be more common
than CSRF token and API token derivations. There are even more URL singing,
etc in
my PHP RFC.


> In particular your suggestion about hash_hkdf was rejected
> unanimously, apart from your own vote
> https://wiki.php.net/rfc/improve_hash_hkdf_parameter and so probably
> shouldn't be brought up for discussion, except if you can bring new
> facts for discussion.
>

If any one of you provided example usages that would be common, valid
(and optimal, it should be optimal since HKDF is designed for the best
possible derived key with HMAC), I would not raise this issue again.


>
> "Not liking the result of the vote" is not a new fact to discuss.
>

Sorry  but, I'm not liking the vote result.
I'm frustrating the fact there is no code example(s) justifies current API
design
that is insecure and inconsistent.


Additionally though, your ideas about adding validation/filter
> functions as a C extension, rather than implementing them in PHP have
> also been resoundingly rejected,
> https://wiki.php.net/rfc/add_validate_functions_to_filter and yet you
> continue to promote the idea. This is also tedious.
>

It's totally new module.
I already replied to your comments in other thread.
Apparently, you are ignoring single responsibility principle.
Please take into the principle into your thoughts.

This pattern of behaviour, continually refusing to accept that other
> people have opinions that don't align with yours, and continually
> bringing up the same topics for discussion over, and over, and over
> again is not productive. It does not make people want to engage you in
> discussion, as it is a waste of their time. This is not something
> other people can fix for you.
>

As I wrote _MANY_ times in past mails.
I would have stopped discussion, if there are example codes that
justify the API.

Sorry for repeating requests, but this is technical list and no evidence
is provided.

If you really think my statements are wrong. Please comment
each line by replying "wrong" so that your idea becomes more clear.
I shouldn't difficult.

I provided more than handful valid use cases in my PHP RFC.
The technical evidence should not be difficult.
It's just example(s).

I'm waiting.

Regards,

-- 
Yasuo Ohgaki
yohg...@ohgaki.net

Re: [PHP-DEV] hash_hkdf() signature and return value

[Dan Ackroyd]

On 6 September 2017 at 02:15, Yasuo Ohgaki  wrote:
> What should we do for this?

Not us, you.

You should start listening to other people's feedback.

You continually refuse to accept any feedback that doesn't agree with
your world-view, not only on the subject of hkdf, but on validation
and other things you think are "MANDATORY"

You should respect RFC votes and stop bringing up the same discussions
over and over again. This is incredibly tedious.

In particular your suggestion about hash_hkdf was rejected
unanimously, apart from your own vote
https://wiki.php.net/rfc/improve_hash_hkdf_parameter and so probably
shouldn't be brought up for discussion, except if you can bring new
facts for discussion.

"Not liking the result of the vote" is not a new fact to discuss.

Additionally though, your ideas about adding validation/filter
functions as a C extension, rather than implementing them in PHP have
also been resoundingly rejected,
https://wiki.php.net/rfc/add_validate_functions_to_filter and yet you
continue to promote the idea. This is also tedious.

This pattern of behaviour, continually refusing to accept that other
people have opinions that don't align with yours, and continually
bringing up the same topics for discussion over, and over, and over
again is not productive. It does not make people want to engage you in
discussion, as it is a waste of their time. This is not something
other people can fix for you.

cheers
Dan
Ack

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] hash_hkdf() signature and return value

[Yasuo Ohgaki]

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:

 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