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

"D. J. Bernstein" <djb@cr.yp.to> Fri, 28 October 2005 21:47 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc40-000227-V6; Fri, 28 Oct 2005 17:47:04 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVc3z-000220-UG for cfrg@megatron.ietf.org; Fri, 28 Oct 2005 17:47:04 -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 RAA21753 for <cfrg@ietf.org>; Fri, 28 Oct 2005 17:46:47 -0400 (EDT)
Received: from stoneport.math.uic.edu ([131.193.178.160]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EVcHd-0006Gh-7N for cfrg@ietf.org; Fri, 28 Oct 2005 18:01:10 -0400
Received: (qmail 78182 invoked by uid 1016); 28 Oct 2005 21:47:22 -0000
Date: Fri, 28 Oct 2005 21:47:22 -0000
Message-ID: <20051028214722.78181.qmail@cr.yp.to>
Automatic-Legal-Notices: See http://cr.yp.to/mailcopyright.html.
From: "D. J. Bernstein" <djb@cr.yp.to>
To: cfrg@ietf.org
Subject: Re: KDF definition and goal [was: [Cfrg] Fwd: Hash-Based Key Derivation]
References: <200510281708.j9SH8TMm005570@taverner.CS.Berkeley.EDU>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f
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

David Wagner writes:
> The hash function also has to be independent of the adversary's choices.

No, that sort of assumption is always wrong for public hash functions.
The adversary remains active after he sees the legitimate users' choice
of hash function.

> If you pick and reveal the hash function first, and the adversary chooses
> their values afterwards (and those values are processed with the hash
> function you picked), all bets are off.  Did I get that right?

If you're trying to say that the attacker can perhaps produce non-random
behavior in the secret that he shares with you, that's true. In fact, he
always knows the entire value! But this has no relevance to his attempts
to determine the secret that you share with someone else.

---D. J. Bernstein, Professor, Mathematics, Statistics,
and Computer Science, University of Illinois at Chicago

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