Re: KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]

David McGrew <mcgrew@cisco.com> Tue, 25 October 2005 23:50 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUYYc-00086f-HT; Tue, 25 Oct 2005 19:50:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EUYYa-00085d-Gz for cfrg@megatron.ietf.org; Tue, 25 Oct 2005 19:50:16 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA07119 for <cfrg@ietf.org>; Tue, 25 Oct 2005 19:50:02 -0400 (EDT)
Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EUYlc-000383-Se for cfrg@ietf.org; Tue, 25 Oct 2005 20:03:46 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 25 Oct 2005 16:50:06 -0700
Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j9PNniJt014063; Tue, 25 Oct 2005 16:49:58 -0700 (PDT)
Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 16:49:57 -0700
Received: from [192.168.1.100] ([10.32.254.212]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 25 Oct 2005 16:49:57 -0700
In-Reply-To: <200510252241.j9PMf4LG023342@taverner.CS.Berkeley.EDU>
References: <200510252241.j9PMf4LG023342@taverner.CS.Berkeley.EDU>
Mime-Version: 1.0 (Apple Message framework v734)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <237B7307-2752-43DE-BB99-55F0CFD1C6D1@cisco.com>
Content-Transfer-Encoding: 7bit
From: David McGrew <mcgrew@cisco.com>
Subject: Re: KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]
Date: Tue, 25 Oct 2005 16:49:55 -0700
To: David Wagner <daw-usenet@taverner.CS.Berkeley.EDU>
X-Mailer: Apple Mail (2.734)
X-OriginalArrivalTime: 25 Oct 2005 23:49:57.0347 (UTC) FILETIME=[CE067330:01C5D9BE]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793
Content-Transfer-Encoding: 7bit
Cc: cfrg@ietf.org
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:cfrg@ietf.org>
List-Help: <mailto:cfrg-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@ietf.org?subject=subscribe>
Sender: cfrg-bounces@ietf.org
Errors-To: cfrg-bounces@ietf.org

Hi David,

thanks for your comments, more inline:

On Oct 25, 2005, at 3:41 PM, David Wagner wrote:

> David McGrew writes:
>
>> Okay, I got carried away and wrote up the following definition and
>> goal for a key derivation function (KDF) which seems appropriate and
>> also seems amenable to reduction-based security proofs.  Comments  
>> welcome.
>>
>
> I'm afraid I don't think this is the right formulation.  Your  
> definition
> is only relevant to practice if we assume that our source of secret
> inputs has a certain special class of distributions: namely, that some
> fixed number of bit positions will be uniformly random and independent
> of everything else.  In many settings this is not realistic.
>

Agreed, the KDF as stated would only be useful for deriving a set of  
keys from a master key, and would not be useful for other problems.

> Consider, for example, using a Diffie-Hellman shared secret g^{xy}
> as your secret input.  This does not come from your special class of
> distributions, since there is no bit position that is independent of
> all others.  Thus proving that a candidate KDF meets your definition
> will not be sufficient to show that the KDF can be safely used with
> Diffie-Hellman shared secrets.  The problem is pervasive and not  
> limited
> to Diffie-Hellman.
>
> I gave a competing definition that I find more useful in practice, and
> that is easy to achieve in the random oracle model, and that  
> guarantees
> the KDF will be secure and useful when applied to any secret input
> whose distribution satisifies a few weak conditions (high min-entropy,
> independence from the hash, efficiently samplable).  I can spell it  
> out
> more precisely if you like, though I don't think there would be  
> anything
> especially new or surprising in a more detailed statement.  The only
> bad news is that my competing definition seems to require that the KDF
> use random oracles, but in my opinion that's not the end of the world.
>

Sure, the random oracle model and KDFs based on it are well  
accepted.  It would be nice to get something based on a reduction- 
based proof, though.

David

_______________________________________________
Cfrg mailing list
Cfrg@ietf.org
https://www1.ietf.org/mailman/listinfo/cfrg