On Wed, Dec 9, 2009 at 3:41 PM, Dan Brown
<dbrown at 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.