What are thoughts on a HKDF_RNG? I think we can place it in the proposed hkdf.h header.
The trick to this generator is there are four inputs (going back to Krawczyk's original design at https://eprint.iacr.org/2010/264.pdf): 1. base keying material (secret or seed) 2. context information (binds security parameters) 3. public salt (optional, ensures uniqueness) 4. length of derived key Context differs from salt. Context might be something like the Protocol Information or TCP/IP pairs of communicating hosts. Each pair using HKDF_RNG will arrive at the same derived secret; but different host pairs will arrive at different derived secrets (with other things being equal). Here's Krawczyk's comments on the importance of contextual information (from page 2): the latter is an important parameter for the KDF intended to include key-related information that needs to be uniquely and cryptographically bound to the produced key material (e.g., a protocol identi er, identities of principals, timestamps, etc.). QUESTION: Should we provide a random number generator based on HKDF? The RandomNumberGenerator interface lacks Krawczyk's contemporary treatment on the subject (http://www.cryptopp.com/docs/ref/class_random_number_generator.html). QUESTION: Do we incorporate an updated interface that hits on Krawczyk's four points? ********** A related question has to do with KDFs in general. In section 3 of his paper, Krawczyk defines four inputs (listed above) for a KDF. But its not clear to me if it applies to a PBKDF. QUESTION: Should we back-fit the four inputs and apply them to PasswordBasedKeyDerivationFunction? The above is somewhat of a trick question because the 4 elements are kind of already there, but its not obvious. Various PBKDFs uses PasswordBasedKeyDerivationFunction (http://www.cryptopp.com/docs/ref/class_password_based_key_derivation_function.html) as a base class. If they are back-fitted, then we can have an inheritance hierarchy similar to: KeyDerivationFunction -> PasswordBasedKeyDerivationFunction KeyDerivationFunction -> HKDF (concrete class) PasswordBasedKeyDerivationFunction -> PKCS12_PBKDF< T > (concrete class) PasswordBasedKeyDerivationFunction -> PKCS5_PBKDF1< T > (concrete class) ... Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
