Am 07.07.2015 um 05:05 schrieb Jeffrey Walton: > >> 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 >> >> <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); The problem with this approach is that we have to somehow define KeyDerivationParameters. What should we include as mandatory functions?
* Context-binding? Not supported by all schemes.
* Iteration count? Not known to some schemes (HKDF, scrypt,...)
* N,R,P? Only known to scrypt.
* ...
We'd have to fit all needs (gigantic interface!) or we'd have to accept
a pointer (or reference) of the base class and make a dynamic_cast to
the proper class providing the needed functionality.
Or we'd have to specialize towards every PBKDF (which we also don't want).
So here's my proposal:
We define KeyDerivationParameters as
class KeyDerivationParameters
{
virtual NameValuePairs Get()=0; // maybe add an implicit conversion?
};
// add virtual void ThrowIfInvalidParameters()=0; to KDF base class
This proposal would have the advantage that we can slim our DeriveKey to
what you've proposed (although with NameValuePairs instead of the
base-class) and we'd still have the freedom to allow each and every KDF
to be fully implemented, as they could specialize the Get() function
(which in turn would be called by the implicit conversion) to only pass
over to the function what is neccessary (n,r,p, salt, saltlength, to
scrypt, iterationcount, salt, saltlength to PBKDF2,...).
As far as implementation goes, we should place those helper classes in
the appropriate header files (hkdf.h, scrypt.h,...) and add a note to
the specific DeriveKey() instance that usage of the specific helper
class is "STRONGLY RECOMMENDED".
Any thoughts on this construction?
BR
JPM
>
> 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]
> <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
