> As you mind bringing up the point of KDFs, we *maybe *should consider > making some sort of "kdf.h", which will feature all KDFs we have in the > library (they're rather simple so we can put them into one header) and we > may also design a standard interface / abstract base class > "KeyDerivationFunction" so people can easily exchange P1363 with HKDF, > after the class has been designed. At the moment we're doing this stuff via > consistency in the definition, but having a base class for our (three?) > KDFs would be better I think... > Yeah, this is the next step. I'm deferring until I see what the Scrypt interface needs.
I know the stuff in pwdbased.h that uses PasswordBasedKeyDerivationFunction is insufficient. PasswordBasedKeyDerivationFunction only provides a purpose byte, and not a full context. The stuff in hkdf.h that uses KeyDerivationFunction lacks an iteration count. To get to a common base class means we need to meld them together. If we do that, then we break ABI compatibility. The break is inevitable, but I'm trying to avoid it (or at least defer it). The first line of hkdf.h looks "wrong" / inconsistent with the rest of the > library (well some don't even have that line :( ) > The standard formulation for this first line is: > > //<filename> - written and placed in the public domain by <author> > > Yeah, I know... Maybe I should use the above, *and* assign the copyright. The problem is the author receives copyright in some countries whether they want it or not. 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.
