Hi Scott and all,
On Thu, Feb 9, 2017 at 10:52 PM, Scott Arciszewski <sc...@paragonie.com>
wrote:
>
>
>> HKDF relies on PRK being cryptographically strong.
>>
>>
>
>
>
> Yes, but 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
