I'm trying to solicit some comments from the crypto side of things at https://crypto.stackexchange.com/questions/26725/software-interface-for-kdf-and-pbkdf.
On Sunday, July 5, 2015 at 11:47:12 PM UTC-4, Jeffrey Walton wrote: > > 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) > ... > -- -- 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.
