rfc:improve_hash_hkdf_pramater

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
Next revisionBoth sides next revision
rfc:improve_hash_hkdf_pramater [2017/02/05 06:23] yohgakirfc:improve_hash_hkdf_pramater [2017/02/05 06:30] yohgaki
Line 167: Line 167:
  
 From user perspective, "salt" and "info" parameters can be used interchangeably. However, it would be good idea to follow RFC 5869 semantics.  From user perspective, "salt" and "info" parameters can be used interchangeably. However, it would be good idea to follow RFC 5869 semantics. 
-Unlike "info" which could be an optional, "salt" cannot be an optional with expiration enabled keys. This kind of expiration is common. e.g. Amazon AWS S3 uses HKDF with expiration to allow access to objects. +Unlike "info" which could be an optional in many cases, "salt" cannot be an optional with expiration enabled keys for instance. This kind of expiration is common. e.g. Amazon AWS S3 uses HKDF with expiration to allow access to objects. 
  
 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't omit salt blindly. It could lead serious security issue. Therefore, salt is better to be required parameter because typical PHP applications can supply salt. 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't omit salt blindly. It could lead serious security issue. Therefore, salt is better to be required parameter because typical PHP applications can supply salt.
rfc/improve_hash_hkdf_pramater.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1