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).
We can fold the Purpose Byte into Context, and then say "a purpose byte is
a context with size 1".
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.
To reiterate, QUESTION: do we do (1) or (2)?
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].
For more options, visit https://groups.google.com/d/optout.
