I think you're right. Sent from my iPad
> On Jul 6, 2015, at 23:05, Jeffrey Walton <[email protected]> wrote: > > >>> 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) >>> ... > This looks about right. > > The last open question is getting scheme specific parameters to the concrete > objects. For that, I think we need a KeyDerivationParameters base class. Wei > even started on it in some time ago in the past (see the commented code in > pwbased.h). Trying to provide parameters through the primary interface is > just mucking up the interface. > > With a KeyDerivationParameters (or similar class), the interface becomes: > > DeriveKey(byte* derived, size_t derivedLen, const KeyDerivationParameters& > params); > > I'm not opposed to NameValuePairs, but I think KeyDerivationParameters is a > better fit. > > Any thoughts? > > 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. -- -- 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.
