Re: [secdir] Secdir review of draft-ietf-karp-crypto-key-table-08.txt

["Klaas Wierenga (kwiereng)" <[e-mail]>]

Russ, Sam,

On Aug 7, 2013, at 5:58 PM, Sam Hartman <[e-mail]> wrote:

>>>>>> "Russ" == Russ Housley <[e-mail]> writes:
> 
>    Russ> Klaas: The property you describe depends on the inputs to the
>    Russ> KDF, not just the definition of the function.
> 
>    Russ> Notice that an IANA registry is defined, and each entry should
>    Russ> point to a definition of the function.
> 
> So, there are a couple of things.
> There are functions that take a random bit string and convert them into
> a key.  For example if you have 56 random bits and want a 64-bit
> correct-parity DES key.
> 
> I don't have  a good name for such a function but it's not a KDF.
> 
> There are functions that take the output of key agreement (DH, ECDH,
> etc) and convernt into a good symmetric key.  I've heard those described
> as key expansion functions or KDFs.
> 
> There are functions that take one symmetric key and turn it into another
> symmetric key so that you can construct a key hierarchy.  I've also seen
> these described as KDFs.  It's probable that any function that's really
> good at taking key agreement output as input and producing a strong key
> will also be good enough  for establishing a key hierarchy.
> 
> I'm not aware of definitive definitions in this space, and I'm fairly
> sure the text we added in 08 is what we mean for this document.

OK, I don't argue that this is what you need at all, so no argument there. The only question I raised is whether one-way is a necessary condition for each and every KDF. I would argue that key stretching not necessarily means one-way .

If you add "in this document" somewhere in the definition I'd be happy, if you don't, no big deal either.

Klaas