Am 06.07.2015 um 05:47 schrieb Jeffrey Walton: > 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 No problem, just introduce an additional function in the derived class. Or we add NameValuePairs somewhere, where "optional" parameters can be added. > > 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? IMO No. For "predictable" RNGs, we have CTR-mode and for good PRNGs this doesn't provide state-recovery and RNGs should /never/ be synchronizable. Maybe we can argue for HKDF-StreamCipher, but HKDF wasn't originally intended as RNG and retro-fitting it as RNG feels like making DES a PBKDF (NTLM Hash). > > 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? We should rather align our RNG interface so it's compatible with NIST's DRBGs and Yarrow / Fortuna (all being "real" RNGs), so we can provide our users "proper" random numbers, which can not be misused as stream-ciphers, a misconception I hear quite often... > > ********** > > 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? > I think the proposal to make a KBKDF class and a PBKDF class (from Crypto.SE), both inheriting from KDF is a good idea, as I've actually never encountered "contextual information" with PBKDFs yet (PBKDF2, bcrypt, scrypt, Argon, ...) don't have it, although it's useful for KBKDFs (HKDF, Skein-KDF, ... all have it). > 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: "Various PBKDFs" = 3 (PBKDF1, PBKDF2, PKCS12-PBKDF)
I'd rather propose: KeyDerivationFunction -> PasswordBasedKeyDerivationFunction KeyDerivationFunction -> KeyBasedKeyDerivationFunction KeyBasedKeyDerivationFunction -> HKDF<T>(concrete class) KeyBasedKeyDerivationFunction -> Skein-KDF(concrete class) PasswordBasedKeyDerivationFunction -> PKCS12_PBKDF<H>(concrete class) PasswordBasedKeyDerivationFunction -> PKCS5_PBKDF2<H>(concrete class) PasswordBasedKeyDerivationFunction -> PKCS5_PBKDF<H>(concrete class) (PasswordBasedKeyDerivationFunction -> bcrypt)(concrete class) PasswordBasedKeyDerivationFunction -> scrypt (concrete class) PasswordBasedKeyDerivationFunction -> PHC_Winner_1 (concrete class) PasswordBasedKeyDerivationFunction -> PHC_Winner_2 (concrete class) PasswordBasedKeyDerivationFunction -> PHC_Winner_3 (concrete class) (assuming there are three winners: Makwa, TMTO resistant (PC targeted), Max-fitting (fits everywhere, servers, embedded,...)) BR JPM > > 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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- -- 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.
smime.p7s
Description: S/MIME Cryptographic Signature
