Re: [PHP-DEV] hash_hkdf() signature

[Yasuo Ohgaki]

Hi Scott and all,

On Thu, Feb 9, 2017 at 10:52 PM, Scott Arciszewski 
wrote:

>
> ​
>> ​HKDF relies on PRK being cryptographically strong.
>> ​
>> ​
>
>
>
> ​Yes, b​ut not for the reasons you might suspect.
>
> ​The main use case of HKDF is to completely prevent related-key attacks,
> while splitting a single key into several for domain-specific purposes.​
> Figuring out a subkey (by sheer luck) should also not give an attacker
> enough information to recreate the IKM.
>
> HKDF isn't meant for key stretching (e.g. use an 80-bit secret in an
> application that requires a 256-bit secret). That's what a password hashing
> function is for. (Bcrypt, Argon2, etc.)
>
> ​
>> ​You should understand users _must_ make sure either "salt" or "IKM" is
>
> strong for HKDF to work. Since hash_hkdf() is generic function, you never
>
> can make sure IKM to be strong always.​
>
> ​​
>
> Not quite. IKM has to be strong. The salt? Not so much.
>
> In cryptography protocols, salts are considered public information (even
> if you don't go out of your way to publish it).
>
> If you have a weak IKM but a strong salt (32 bytes from random_bytes()),
> you should still consider the OKM weak.
> ​
>
>> 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.
>
>
>
> Don't get me wrong: Having secure random salts is useful (serves as a
> useful way to enlarge the effective nonce in a symmetric encryption
> protocol).
>
> But the cryptographic secret in this protocol is IKM. Not the salt.
>

I agree that your description matches many typical crypto
encryptions/authentication/etc.
As you would know, there are some exceptions that encryption key is not
really a random
(Not cryptographically strong) If user could use strong IKM, they should
use it, then
salt could be for additional security. (HKDF IKM could be weak, salt could
be secret, but
you mentioned typical use case and best practice in crypto)

The most typical HKDF application with PHP is access token key derivations
with timestamp
such as CSRF and Object Access token. For these applications, salt usage is
strongly
recommended, info(context) is recommended, length is OK with hash default.

e.g.
Generating CSRF token keys
$expire = time()+900; // Even, non secret, low entropy salt makes HKDF OKM
significantly stronger.
$csrf_token = bin2hex(hash_hkdf('sha256', $_SESSION['CSRF_TOKEN_SEED'], 0,
'', $expire));
then, send $expire and $csrf_token as access key.

This could be done with hash_hmac() already.
$csrf_token = hash_hmac('sha256', $_SESSION['CSRF_TOKEN_SEED'], $expire));

What's really good about HKDF is it can add additional non secret optional
context(domain) safely, as you mentioned.
// Make CSRF token only valid to 'Admin' features.
$csrf_token = bin2hex(hash_hkdf('sha256', $_SESSION['CSRF_TOKEN_SEED'], 0,
'Admin', $expire));
// Should be OK, but this is risky compare to above.
$csrf_token = hash_hmac('sha256', $_SESSION['CSRF_TOKEN_SEED'], $expire.
'-Admin'));

Regards,

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

[PHP-DEV] BAD Benchmark Results for PHP Master 2017-02-08

[lp_benchmark_robot]

Results for project PHP master, build date 2017-02-08 20:28:50-08:00
commit: 4ec8066
previous commit:31332d0
revision date:  2017-02-08 01:10:54+01:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores, 
stepping 2, LLC 45 MB
mem:128 GB
os: CentOS 7.1
kernel: Linux 3.10.0-229.4.2.el7.x86_64

Baseline results were generated using release php-7.0.0, with hash 60fffd2 from
2015-12-01 04:16:47+00:00

---
benchmark   relative   change since   change since  
current rev run
std_dev*   last run   baseline  
   with PGO
---
:-|   Wordpress 4.2.2 cgi -T1  0.20%  0.11% -0.16%  
  7.73%
:-|   Drupal 7.36 cgi -T1  0.17% -0.11% -0.10%  
  5.07%
:-|   MediaWiki 1.23.9 cgi -T5000  0.07% -0.12%  1.04%  
  3.33%
:-|   bench.php cgi -T100  0.10% -0.03% 38.01%  
 -7.51%
:-|  micro_bench.php cgi -T10  0.01% -0.70% 14.03%  
  3.62%
:-(  mandelbrot.php cgi -T100  1.00% -2.81% 26.91%  
 -1.64%
---

* Relative Standard Deviation (Standard Deviation/Average)

If this is not displayed properly please visit our results page here: 
http://languagesperformance.intel.com/bad-benchmark-results-for-php-master-2017-02-08/

Note: Benchmark results for Wordpress, Drupal, MediaWiki are measured in
fetches/second while all others are measured in seconds.
More details on measurements methodology at: 
https://01.org/lp/documentation/php-environment-setup.

Subject Label Legend:
Attributes are determined based on the performance evolution of the workloads
compared to the previous measurement iteration.
NEUTRAL: performance did not change by more than 1% for any workload
GOOD: performance improved by more than 1% for at least one workload and there
is no regression greater than 1%
BAD: performance dropped by more than 1% for at least one workload and there is
no improvement greater than 1%
UGLY: performance improved by more than 1% for at least one workload and also
dropped by more than 1% for at least one workload


Our lab does a nightly source pull and build of the PHP project and measures
performance changes against the previous stable version and the previous nightly
measurement. This is provided as a service to the community so that quality
issues with current hardware can be identified quickly.

Intel technologies' features and benefits depend on system configuration and may
require enabled hardware, software or service activation. Performance varies
depending on system configuration.


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

Re: [PHP-DEV] Improve (disable|enable)_functions #65386

[Sara Golemon]

On Thu, Jan 19, 2017 at 6:18 AM, Ben RUBSON  wrote:
> As proposed by cmb (thank you !), I open a discussion regarding req #65386 :
> https://bugs.php.net/bug.php?id=65386
>
> It summarizes requests around disable_functions directive :
> - modification of disable_functions to be a PHP_INI_SYSTEM directive ;
>
Could you clarify? `disable_functions` *IS* a PHP_INI_SYSTEM directive:

PHP_INI_ENTRY("disable_functions", "", PHP_INI_SYSTEM, NULL)

> - implementation of enable_functions as a PHP_INI_SYSTEM directive ;
>
I'm not a big fan of a whitelist for weakening/overriding a blacklist setting.

There's also a technical hurdle here due to the way that functions are
(currently) disabled.  It's INI_SYSTEM because enabling/disabling on a
per-request (per vhost essentially means per request) basis means a
lot more heavy lifting than disabling on a system-wide level (we just
replace the function implementation in the global table with a STFU
message).

func->handler = ZEND_FN(display_disabled_function);


> - support of wildcards in these 2 directives.
>
I could potentially get down with wildcards.  It's way easier to
exhaustively cover an entire class of functions, but if the goal is to
disable an entire extension's worth of functions, wouldn't one
just not load that extension?

I understand this part makes more sense with the `enable_functions`
idea, but... see above.

-Sara

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

[PHP-DEV] Re: Improve (disable|enable)_functions #65386

[Ben RUBSON]

> On 19 Jan 2017, at 12:18, Ben RUBSON  wrote:
> 
> Hello,
> 
> As proposed by cmb (thank you !), I open a discussion regarding req #65386 :
> https://bugs.php.net/bug.php?id=65386
> 
> It summarizes requests around disable_functions directive :
> - modification of disable_functions to be a PHP_INI_SYSTEM directive ;
> - implementation of enable_functions as a PHP_INI_SYSTEM directive ;
> - support of wildcards in these 2 directives.
> 
> As a result, we would then for example be able to disable functions in 
> php.ini,
> and re-enable some of them in some of the virtualhosts of the httpd.conf.
> And using wildcards, to quickly/exhaustively work on a bunch of func : pcntl_*
> 
> Thank you very much for your interest and support !
> 
> Best regards,
> 
> Ben

Hi,

Any thoughts ?

Many thanks !

Ben


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

Re: [PHP-DEV] hash_hkdf() signature

[Scott Arciszewski]

On Thu, Feb 9, 2017 at 7:51 AM, Yasuo Ohgaki  wrote:

> Hi Andrey,
>
> How the manual page would be. Would it be
>
>   "Even though 'slat' is the last optional parameter that users may omit
> easily
> by mistake, users _must_ set strong salt for weak $ikm. This is
> mandatory
> requirement for HKDF to work. In addition, it is advices to set salt
> whenever
> possible as RFC 5689 recommends"
>
> It can't make sense for new function.
>
> On Thu, Feb 9, 2017 at 7:59 PM, Andrey Andreev  wrote:
>
>>
>> The fact that you continue to talk about passwords and other low-entropy
>> data as IKM shows, yet again, that you don't understand HKDF.
>> It is simply not a password-based KDF; if you want that - use PBKDF2.
>> Please read Section 4* of the spec: https://tools.ietf.org/html/rf
>> c5869.html#section-4
>>
>
> PHP would not be a language that builds low level crypto library/feature.
> I'm not sure what you mean by this. What sentences you refer as I don't
> understand?
>
> I assumed you would like to derive human typable password because
> you prefer to have the most priority for "length". Do you have any typical
> "length" use with PHP?
>
> HKDF relies on PRK being cryptographically strong.
>
> Extract step
>PRK = HMAC-Hash(salt, IKM)
>
> You should understand users _must_ make sure either "salt" or "IKM" is
> strong for HKDF to work. Since hash_hkdf() is generic function, you never
> can make sure IKM to be strong always.
>
> With this fact alone, salt must have the most priority.
>
>
>> In fact, at one point I suggested the function be named just 'hkdf()' as
>> a way of discouraging such misuse, because a lot of people associate the
>> word "hash" with password handling.
>>
>
>> And this ...
>>
>>
>>> 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.
>>>
>>>
>> Shows that you shouldn't be trusted with anything related to cryptography
>> either.
>> I may be no cryptographer myself, but one thing I know for sure is that
>> shorter than required key lengths are *never* ok, and most encryption
>> algorithms have a *fixed* key length.
>>
>
> Are you assuming converting crypto keys to be other length would be
> the typical HKDF usage with PHP?
> Then, I have to say your assumption is wrong.
>
> It would be most used for CSRF key generation, object access
> control, e.g. AWS S3 presigned URL, or anything related to web
> app, not low level crypto.
>
> Discussion so far would not justify use of vulnerable, i.e. PRK could
> be weak very easily, signature.
>
> And you don't answer questions to you:
>
> 
> Why you recommends following usage?
> hash_hkdf('sha256', $weak_ikm, 9); // We can generate strong key easily,
> Nice! <= Must not do this.
> 
>
> 
> What's the reason why you trying to disregard RFC 5869 strongly recommends?
> 
>
> 
> 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.
> 
>
> 
> BTW, I don't think of typical PHP application that requires
> human typable short password with HKDF. What kind of
> application would be?
> 
>
>
>
> Regards,
>
> --
> Yasuo Ohgaki
> yohg...@ohgaki.net
>

​Hi,

​
> ​HKDF relies on PRK being cryptographically strong.
> ​
> ​



​Yes, b​ut not for the reasons you might suspect.

​The main use case of HKDF is to completely prevent related-key attacks,
while splitting a single key into several for domain-specific purposes.​
Figuring out a subkey (by sheer luck) should also not give an attacker
enough information to recreate the IKM.

HKDF isn't meant for key stretching (e.g. use an 80-bit secret in an
application that requires a 256-bit secret). That's what a password hashing
function is for. (Bcrypt, Argon2, etc.)

​
> ​You should understand users _must_ make sure either "salt" or "IKM" is

strong for HKDF to work. Since hash_hkdf() is generic function, you never

can make sure IKM to be strong always.​

​​

Not quite. IKM has to be strong. The salt? Not so much.

In cryptography protocols, salts are considered public information (even if
you don't go out of your way to publish it).

If you have a weak IKM but a strong salt (32 bytes from random_bytes()),
you should still consider the OKM weak.
​

> 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.



Don't get me wrong: 

Re: [PHP-DEV] hash_hkdf() signature

[Yasuo Ohgaki]

Hi Andrey,

How the manual page would be. Would it be

  "Even though 'slat' is the last optional parameter that users may omit
easily
by mistake, users _must_ set strong salt for weak $ikm. This is
mandatory
requirement for HKDF to work. In addition, it is advices to set salt
whenever
possible as RFC 5689 recommends"

It can't make sense for new function.

On Thu, Feb 9, 2017 at 7:59 PM, Andrey Andreev  wrote:

>
> The fact that you continue to talk about passwords and other low-entropy
> data as IKM shows, yet again, that you don't understand HKDF.
> It is simply not a password-based KDF; if you want that - use PBKDF2.
> Please read Section 4* of the spec: https://tools.ietf.org/html/
> rfc5869.html#section-4
>

PHP would not be a language that builds low level crypto library/feature.
I'm not sure what you mean by this. What sentences you refer as I don't
understand?

I assumed you would like to derive human typable password because
you prefer to have the most priority for "length". Do you have any typical
"length" use with PHP?

HKDF relies on PRK being cryptographically strong.

Extract step
   PRK = HMAC-Hash(salt, IKM)

You should understand users _must_ make sure either "salt" or "IKM" is
strong for HKDF to work. Since hash_hkdf() is generic function, you never
can make sure IKM to be strong always.

With this fact alone, salt must have the most priority.


> In fact, at one point I suggested the function be named just 'hkdf()' as a
> way of discouraging such misuse, because a lot of people associate the word
> "hash" with password handling.
>

> And this ...
>
>
>> 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.
>>
>>
> Shows that you shouldn't be trusted with anything related to cryptography
> either.
> I may be no cryptographer myself, but one thing I know for sure is that
> shorter than required key lengths are *never* ok, and most encryption
> algorithms have a *fixed* key length.
>

Are you assuming converting crypto keys to be other length would be
the typical HKDF usage with PHP?
Then, I have to say your assumption is wrong.

It would be most used for CSRF key generation, object access
control, e.g. AWS S3 presigned URL, or anything related to web
app, not low level crypto.

Discussion so far would not justify use of vulnerable, i.e. PRK could
be weak very easily, signature.

And you don't answer questions to you:


Why you recommends following usage?
hash_hkdf('sha256', $weak_ikm, 9); // We can generate strong key easily,
Nice! <= Must not do this.



What's the reason why you trying to disregard RFC 5869 strongly recommends?



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.



BTW, I don't think of typical PHP application that requires
human typable short password with HKDF. What kind of
application would be?




Regards,

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

Re: [PHP-DEV] hash_hkdf() signature

[Andrey Andreev]

Hi Yasuo,

The fact that you continue to talk about passwords and other low-entropy
data as IKM shows, yet again, that you don't understand HKDF.
It is simply not a password-based KDF; if you want that - use PBKDF2.
Please read Section 4* of the spec:
https://tools.ietf.org/html/rfc5869.html#section-4

In fact, at one point I suggested the function be named just 'hkdf()' as a
way of discouraging such misuse, because a lot of people associate the word
"hash" with password handling.

And this ...


> 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.
>
>
Shows that you shouldn't be trusted with anything related to cryptography
either.
I may be no cryptographer myself, but one thing I know for sure is that
shorter than required key lengths are *never* ok, and most encryption
algorithms have a *fixed* key length.

Also, this is the last time I reply to you on this topic. You're just
impossible to reason with.

Cheers,
Andrey.