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

David Wagner <daw@cs.berkeley.edu> Thu, 27 October 2005 05:53 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV0hS-0002K9-8r; Thu, 27 Oct 2005 01:53:18 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV0hO-0002Hy-1r for cfrg@megatron.ietf.org; Thu, 27 Oct 2005 01:53:14 -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 BAA25851 for <cfrg@ietf.org>; Thu, 27 Oct 2005 01:52:57 -0400 (EDT)
Received: from taverner.cs.berkeley.edu ([128.32.168.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV0ue-0001EU-U5 for cfrg@ietf.org; Thu, 27 Oct 2005 02:06:59 -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 j9R5qgdF015531 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 26 Oct 2005 22:52:42 -0700
Received: (from daw@localhost) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1/Submit) id j9R5qgY9015527; Wed, 26 Oct 2005 22:52:42 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200510270552.j9R5qgY9015527@taverner.CS.Berkeley.EDU>
Subject: KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]
To: cfrg@ietf.org
Date: Wed, 26 Oct 2005 22:52:42 -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: 50a516d93fd399dc60588708fd9a3002
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

Simon Blake-Wilson writes:
>min-entropy is an information-theoretic, as opposed to complexity
>theoritic, concept, isn't it?

(These are not stupid questions, by the way.)

True.  Actually, I believe that the 2-universal extractor also works
in the case where the input distribution is computationally indistinguishable
from a source with high min-entropy.

Warning: We're at the edge of my knowledge.  My understanding of the
subject of extractors is pretty sketchy.  I know there are others on
this list who know more; maybe they will chime in.

>I think it would be a great contribution to spell out a good definition.
>One comment though: I think a more palatable definition would be to take
>an unpredictable input and produce an indistinguishable output, in the
>face of an oracle that gives access to various other bits of the output.

Ok.  Let me give it a try:

Let D be a source distribution with min-entropy >= m.
Let S be a sampling algorithm: a randomized algorithm so that
the output of S() is computationally indistinguishable from D,
and so that S() is efficient.

Let H be a random oracle.
(Note: S is not permitted to invoke H, so S is independent of H.)

Let F be a KDF algorithm.  Namely, F is an algorithm that uses an
oracle (H) and accepts two inputs (K,X) and produces an output (Y).
Let R be a random function mapping X to Y.

Say that F is a (t,q,e)-secure KDF for S if for all adversaries A
running in time at most t and making at most q queries, Adv A <= e, where
  Adv A = |Pr[K <- S(); A^{F(K,.),H}=1] - Pr[A^{R(.),H}=1]|
where q counts the number of queries to A's first oracle.

Also we have the notion of a scheme F that is a (t,q,e)-secure KDF
for some class of distributions (e.g., for all distributions with
min-entropy >= m).

The chosen-input queries correspond to cases where the attacker
controls the auxiliary inputs X and somehow manages to learn the
session key (e.g., it leaks; it is cryptanalyzed; an endpoint is
hacked).

The above is probably pretty rough, and maybe there is a better
formalization; any thoughts?

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