> 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.
