Re: [Cfrg] Fwd: Can CMAC and/or GMAC be substituted in an HMAC-styledKDF?

On Wed, Dec 9, 2009 at 3:41 PM, Dan Brown <dbrown@certicom.com> wrote:

> This raises a minor, non-security issue: isn't a KDF a lower level
> primitive than a MAC?  E.g. the key in a MAC is one of the intended purposes
> of the output of a KDF, not the other way.   If so, isn't it architecturally
> awkward to define a KDF that has built-in component of a MAC?  E.g. HKDF has
> HMAC built-in.
>

We are building HKDF on HMAC not on a generic MAC (did I say that before?)
We are using specific properties of the HMAC scheme (with suitable
assumptions on the underlying hash function) and not those of a MAC.
If at all, we are building on HMAC being a PRF since we are using it for the
expansion part as such.

But for extraction you need other properties.  These properties change
according to the usage scenario and what you can assume about your source of
keying material. In some cases you need to assume more than a MAC and PRF,
namely, model the hash function as a random oracle (especially when you do
not have a salt value and you need to output almost all entropy of the
source). In other cases, you need MUCH LESS than PRF/MAC, namely, just
properties of universal hashing from the underlying hash function. Such
properties are combinatorial in nature and do not require, in principle,
computational assumptions let alone the idealized modeling of random
oracles.

So, for extraction, sometimes you are assuming more from the hash functions
than what you need for MAC/PRF and sometimes less.

But however you define the KDF functionality, and however you build it,
remember that a KDF is in particular a PRF (this is actually the easy case,
when your source of keying material is uniform or pseudo-random and you need
to produce more pseudorandom bits than the input). Thus for the whole
construction you cannot avoid having some form of pseudorandomness
assumption.

> More philosophically, is building new primitives from old primitives, where
> the old have to do more than their original aim (e.g. HMAC as more than MAC,
> SHA1 as more than CRHF) the wisest approach?  Does it put too much reliance
> on these retrofitted primitives?
>

If you can build a generic KDF based on MAC and collision resistance only,
you are more than welcome to present it.
Remember that you will need to first be able to build a PRF out of these
properties, a simpler task which I do not know how to accomplish.

On the other hand, why rely on collision resistance which may be the weakest
point of hash functions anyway?

Would you feel better with the traditional KDFs of the form Hash (SKM||1) ||
Hash(SKM||2)||...
that may only be justified assuming Hash is a random oracle (which is more
than a MAC, PRF, collision resistance, universal hashing, etc,)???
Would you even buy that construction as a PRF (which as said, is a
particular case of a KDF)??

Hugo

> ---------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential
> information, privileged material (including material protected by the
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg
>