Hey Jeff, Am 03.07.2015 um 13:29 schrieb Jeffrey Walton: > > 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 can tell you this: Three parameters. "Iteration Count" = N = [1;64] or [2^1;2^64], depending on if we agree to use 2^N or to use plain N as input. "Parallelization Value" = P = 1 or 2 usually "Memory Bandwidth Value" = R = 8 is default
> > 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. Is HKDF defined with an iteration count? I think we /may/ want to make PBKDF a child-class of KDF, but we definitely don't want both to have the exact same interface as PBKDFs need parameters that KDFs don't. As a starting point, when facing the problem of the re-design of the PBKDF interface I took the approach as can be found in my pwdbased.h <https://github.com/DevJPM/CryptoJPM/blob/master/Source/CryptoPP/pwdbased.h> The idea is to extend the class with functionality absolutely required and add anything that is considered a "nice bonus" at end-node-level. I "stole" this concept from other classes (don't remember which exactly), which had a mandatory interface (as defined for PHC, meaning tweakable mcost and tcost) and to add anything special to the algorithm (like secret-key-input) at node-class level. The .cpp file also provides standard implementations of some of the defined functions, which should be overridden if a more efficient way is known. BR JPM > > 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] > <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
