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 03:03] – 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:// |
- | hash_hkdf() is added to master without RFC already. It has following signature currently. | + | * https:// |
+ | * https:// | ||
+ | * https:// | ||
+ | |||
+ | hash_hkdf() is added to master without | ||
< | < | ||
Line 18: | Line 22: | ||
Issue is parameter order and handling. | Issue is parameter order and handling. | ||
- | RFC 5869 notes for HKDF users. It states, | + | RFC 5869 " |
< | < | ||
Line 81: | Line 85: | ||
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." | 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 " | + | 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 100: | 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 106: | 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 124: | 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 132: | Line 150: | ||
===== Proposal ===== | ===== Proposal ===== | ||
- | Internet RFC clearly recommends " | + | Internet RFC clearly recommends " |
- | Change hash_hkdf() from | + | Change hash_hkdf() |
< | < | ||
Line 149: | Line 167: | ||
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. | + | 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. |
===== Discussions ===== | ===== Discussions ===== |
rfc/improve_hash_hkdf_pramater.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1