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

David Wagner <daw@cs.berkeley.edu> Fri, 28 October 2005 02:42 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKCO-0003T3-6q; Thu, 27 Oct 2005 22:42:32 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVKCM-0003Qk-2v for cfrg@megatron.ietf.org; Thu, 27 Oct 2005 22:42:30 -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 WAA13305 for <cfrg@ietf.org>; Thu, 27 Oct 2005 22:42:14 -0400 (EDT)
Received: from taverner.cs.berkeley.edu ([128.32.168.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVKPp-0004Qd-6Q for cfrg@ietf.org; Thu, 27 Oct 2005 22:56:26 -0400
Received: from taverner.CS.Berkeley.EDU (localhost.localdomain [127.0.0.1]) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1) with ESMTP id j9S2gCLI013240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 19:42:12 -0700
Received: (from daw@localhost) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1/Submit) id j9S2gCbL013236; Thu, 27 Oct 2005 19:42:12 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200510280242.j9S2gCbL013236@taverner.CS.Berkeley.EDU>
Subject: KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]
To: cfrg@ietf.org
Date: Thu, 27 Oct 2005 19:42:12 -0700
Secret-Bounce-Tag: 9a029cbee41caf2ca77a77efa3c13981
X-Mailer: ELM [version 2.5 PL6]
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3
Content-Transfer-Encoding: 7bit
X-BeenThere: cfrg@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
Reply-To: David Wagner <daw-usenet@taverner.CS.Berkeley.EDU>
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

David McGrew writes:
>On Oct 25, 2005, at 5:25 PM, David Wagner wrote:
>> One practical problem with randomized KDFs is that it can be a little
>> tricky to figure out how to pick R.
>> If two parties want to agree on a
>> session key, derived using the KDF, they both need the same value  
>> of R.
>> The obvious thing is to have R be chosen by one party and then sent in
>> the clear to the other.  That works if R was chosen honestly.   
>> However,
>> if R is chosen maliciously by one of the parties, I think everything
>> could blow up and all security could be lost.
>
>I agree that caution is needed, but I'm not sure that this is such a  
>problem.  If we assume that Alice doesn't reveal a secret key, then  
>it seems safe to assume that she will honestly choose the KDF- 
>randomizer used to derive that key.

I don't think this is safe at all.  I think there can be real-world
scenarios with real security holes (not just a theoretical inability
to prove the scheme secure).  Suppose Alice is sending a message to Bob.
Let me consider confidentiality and message authentication separately.


Message authentication: If Alice chooses the randomizer R, then I think
all security can be lost.  Mallory might choose the randomizer R in a way
that makes it easy for her to predict the resulting session key, and then
Mallory will be able to forge messages that look like they came from Alice.

For example, consider the following protocol where Alice sends M to Bob:
  A->B: A, R, M, MAC(k,M)   where k = UH(R, g^{ab})
where Alice has a static Diffie-Hellman exponent g^a and Bob has g^b,
where UH((\alpha,\beta), X) = \alpha * X + \beta mod p for some fixed
prime p, and where Alice chooses R = (\alpha,\beta) randomly.

This protocol is broken.  Mallory can send impersonate Alice:
  M->B: A, (0,0), M, MAC(0,M)
Bob will think that M came from Alice, since UH((0,0), X) = 0 for
all X, and consequently the session key Bob derives is predictable.


Confidentiality: If Bob chooses the randomizer R, then I think all
security can be lost.  Mallory might choose the randomizer R in a way
that makes it easy for her to predict the resulting session key, and
then Mallory will be able to read messages Alice is trying to send to Bob.

For example, consider the following protocol where Alice sends M to Bob:
  B->A: B, R
  A->B: Encrypt(k,M)   where k = UH(R, g^{ab})
where everything is as above, except this time Bob picks R.

This protocol is broken.  Mallory can snoop on Bob's traffic:
  M->A: B, (0,0)
  A->M: Encrypt(k,M)   where k = UH((0,0), g^{ab})
Mallory will be able to recover M, since she can predict that k=0 and
thus she can decrypt the ciphertext that Alice sent.

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