Archive

I would add that a function that "merely" adds parity to a DES key is a singularly bad example, which is long gone and does not need to be resurrected.

TNX!

Sent from my iPad

On Aug 9, 2013, at 8:28, Uri Blumenthal <uri@MIT.EDU> wrote:

> IMHO, yes - a KDF must be one-way. Including "key-stretcher" functions.
> 
> TNX!
> 
> Sent from my iPad
> 
> On Aug 9, 2013, at 4:48, "Klaas Wierenga (kwiereng)" <kwiereng@cisco.com> wrote:
> 
>> Russ, Sam,
>> 
>> On Aug 7, 2013, at 5:58 PM, Sam Hartman <hartmans@PAINLESS-SECURITY.COM> wrote:
>> 
>>>>>>>> "Russ" == Russ Housley <housley@vigilsec.com> 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
>> 
>> 
>> 
>> _______________________________________________
>> secdir mailing list
>> secdir@ietf.org
>> https://www.ietf.org/mailman/listinfo/secdir
>> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

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