rfc:improve_hash_hkdf_pramater
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:improve_hash_hkdf_pramater [2017/02/05 01:53] – Due to sctict_types, empty string must be allowed yohgaki | rfc:improve_hash_hkdf_pramater [2017/02/05 06:30] – yohgaki | ||
---|---|---|---|
Line 8: | Line 8: | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | HKDF is informational internet standard defined by [[https:// | + | HKDF is informational internet standard defined by [[https:// |
+ | |||
+ | * https:// | ||
+ | * https:// | ||
+ | * https:// | ||
+ | |||
+ | hash_hkdf() is added to master without | ||
< | < | ||
Line 16: | Line 22: | ||
Issue is parameter order and handling. | Issue is parameter order and handling. | ||
- | RFC 5869 notes for HKDF users. It states, | + | RFC 5869 " |
< | < | ||
- | HKDF is defined to operate with and without random salt. This is | + | **HKDF is defined to operate with and without random salt. This is |
done to accommodate applications where a salt value is not available. | done to accommodate applications where a salt value is not available. | ||
- | We stress, however, that the use of salt adds significantly to the | + | **We stress, however, that the use of **salt adds significantly to the |
- | strength of HKDF, ensuring independence between different uses of the | + | strength of HKDF**, ensuring independence between different uses of the |
hash function, supporting " | hash function, supporting " | ||
strengthening the analytical results that back the HKDF design. | strengthening the analytical results that back the HKDF design. | ||
Line 56: | Line 62: | ||
</ | </ | ||
- | As you can see from the RFC, it states even weak salt can make HKDF result much stronger than without salt. Thus users should supply salt whenever it is possible even if it can be omitted. HKDF is designed to be stronger with salt. | + | < |
+ | 3.2. The ' | ||
+ | |||
+ | While the ' | ||
+ | often of great importance in applications**. | ||
+ | bind the derived key material to application- and context-specific | ||
+ | information. | ||
+ | algorithm identifiers, | ||
+ | prevent the derivation of the same keying material for different | ||
+ | contexts (when the same input key material (IKM) is used in such | ||
+ | different contexts). | ||
+ | the key expansion part, if so desired (e.g., an application may want | ||
+ | to bind the key material to its length L, thus making L part of the | ||
+ | ' | ||
+ | should be independent of the input key material value IKM. | ||
+ | </ | ||
+ | |||
+ | As you can see from the RFC, it states even weak "salt" | ||
+ | |||
+ | The RFC described " | ||
+ | |||
+ | As the RFC 3.1 states "HKDF is defined to operate with and without random salt. This is done to accommodate applications where a salt value is not available." | ||
+ | |||
+ | The RFC describes " | ||
==== hash_hkdf() applications ===== | ==== hash_hkdf() applications ===== | ||
- | This RFC only describes 2 examples, but there are many HKDF application. e.g. Object Store, etc. Developers must consider salt use for better security rather than omitting salt without proper consideration. | + | Typical PHP HKDF application can be used with " |
+ | |||
+ | Please note that HKDF is designed for super secret key like master key for critical systems. There is nothing wrong to use with hash_password() generated string as input key. | ||
=== Per user data encryption === | === Per user data encryption === | ||
- | - Get the password hash generated by hash_password() for the user | + | - Get the secret |
- | - Get application secret salt stored in secure place. | + | - Get application secret salt stored in secure place. |
- | - Generate HKDF hash value with 1 and 2 by hash_hkdf() | + | - Generate HKDF hash value with 1 and 2. < |
- Encrypt the user data with the key from 3 | - Encrypt the user data with the key from 3 | ||
Line 74: | Line 106: | ||
See also **Security Note** section blow. The same technique can be used for per user encryption key. | See also **Security Note** section blow. The same technique can be used for per user encryption key. | ||
+ | |||
+ | Other way to encrypt per user | ||
+ | |||
+ | - Get system shared secret encryption key from secure place. $ikm | ||
+ | - Get user ID which is unique in the system. $info | ||
+ | - Generate HKDF hash value 1 and 2. < | ||
+ | |||
+ | |||
+ | Note that both method uses " | ||
+ | |||
+ | There are many usages other than these two. Users can choose appropriate method for their needs. | ||
+ | |||
=== CSRF token === | === CSRF token === | ||
Line 80: | Line 124: | ||
Setting up CSRF token | Setting up CSRF token | ||
- | - Get expiration timestamp | + | - Get expiration timestamp. ($salt) |
- | - Generate HKDF value with 1 and session ID | + | - Generate HKDF value with 1 and session ID ($ikm). |
- | - Send key from 2 and timestamp from 1 to browser as CSRF token | + | - Send key from 2 and timestamp from 1 to browser as CSRF token. |
Verifying CSRF token | Verifying CSRF token | ||
- | - Get HKDF key and timestamp(salt) value from request | + | - Get HKDF key and timestamp($salt) value from request. |
- | - Check if timestamp is not expired | + | - Check if timestamp is not expired. |
- | - Generate HKDF value session ID and timestamp(salt) | + | - Generate HKDF value from session ID($ikm) |
- | - Compare HKDF value sent by browser and server generated HKDF value if it matches | + | - Compare HKDF value sent by browser and server generated HKDF value if it matches. |
Secure CSRF token expiration can be defined with this method regardless of session ID lifetime. i.e. You can set short CSRF token expiration securely. | Secure CSRF token expiration can be defined with this method regardless of session ID lifetime. i.e. You can set short CSRF token expiration securely. | ||
Line 98: | Line 142: | ||
https:// | https:// | ||
- | Therefore, use of session ID as CSRF token key source is not recommended. You are better to use separate key for CSRF token generation in $_SESSION. e.g. $_SESSION[' | + | Therefore, use of session ID as CSRF token key source is not recommended. You are better to use separate key for CSRF token generation in $_SESSION. e.g. $_SESSION[' |
==Use of info parameter== | ==Use of info parameter== | ||
Line 106: | Line 150: | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | Internet RFC clearly recommends " | + | Internet RFC clearly recommends " |
- | Change hash_hkdf() from | + | Change hash_hkdf() |
< | < | ||
Line 118: | Line 162: | ||
< | < | ||
string hash_hkdf(string algo, string ikm, string salt [, string info = '' | string hash_hkdf(string algo, string ikm, string salt [, string info = '' | ||
+ | - Set NULL to use without salt, raise exception for empty string. | ||
- Note: length is only used for internal execution optimization. It will set to proper value according to inputs. | - Note: length is only used for internal execution optimization. It will set to proper value according to inputs. | ||
</ | </ | ||
From user perspective, | From user perspective, | ||
- | Unlike " | + | Unlike " |
+ | |||
+ | Typical PHP applications that need HKDF can use (or should use) salt for security reasons as examples above. Users should consider if salt can be used or not. If use of salt is impossible, then it should set to be empty. Users shouldn' | ||
===== Discussions ===== | ===== Discussions ===== |
rfc/improve_hash_hkdf_pramater.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1