Am 03.07.2015 um 21:57 schrieb Jeffrey Walton: > OK, so what's the verdict here? Do we: > > (1) allow the HKDF check-in, and sort out the interface later? > > or > > (2) hold off on the check-in, and work through the interface > issues now? > > I'm in favor of (1), but others may not be. > > If we tackle (2) now, then wee need to handle three distinct cases for > DeriveKey: > > * KDF - lacks iteration count, lacks time limit, possible context > block > * PBKDF - iteration count, time limits, possible purpose byte > (rather than context block) > * (Memory) Hard KDF - iteration count, work factor (possibly > log_2), parallelization, memory bandwidth > > The Memory Hard KDF may also use a purpose byte or context block. (I > need to read the spec, so this may not be strictly true). > IIRC at least scrypt doesn't need this. > We can fold the Purpose Byte into Context, and then say "a purpose > byte is a context with size 1". Sounds like a good way to go, this will simplify our interface. > > We also probably need to move the common base classes into cryptlib.h, > which is where a lot of the interfaces that define behaviors live. Absolutely if we make sure, our design work is good. > > To reiterate, QUESTION: do we do (1) or (2)? For the moment I'd say, let's do (1): Make a unique version for HKDF (/maybe/ make sure it's a drop-in replacement for P1363-KDF2) and defer revamp of the whole KDF interfaces until we actually have cases at hand where we have to worry about the interface, meaning that we should at least wait until PHC finished (Q3 atm). I think the point where we actually need to decide and work on the interface will be, when I start proposing merges from my CryptoJPM into Crypto++. IIRC scrypt was around point three on that TO-DO list, we'll have to tackle some Skein / BLAKE2 stuff first. And point 4 will likely be PHC-winner(s), even more as tendencies seem to be that Makwa (having some very special and unique property in this competition) will be a winner along with others, meaning we can't even decide what to bring into the base-class(es).
Another note: I think the mentioned "memory-hard KDF" is misleading. Scrypt is a PBKDF. As are bcrypt and PBKDF2 (and probably at least one PHC-winner). They all should share the same base interface, but different specialized classes. But it's not the time yet to discuss these issues :) BR JPM > > Jeff > > On Friday, July 3, 2015 at 3:02:34 PM UTC-4, jean-pierre.muench wrote: > > 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. > > -- > -- > 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
