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

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

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVJwR-0002Dk-Ow; Thu, 27 Oct 2005 22:26:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EVJwQ-0002Df-Dw for cfrg@megatron.ietf.org; Thu, 27 Oct 2005 22:26:02 -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 WAA12404 for <cfrg@ietf.org>; Thu, 27 Oct 2005 22:25:46 -0400 (EDT)
Received: from taverner.cs.berkeley.edu ([128.32.168.222]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EVK9q-0003x4-9s for cfrg@ietf.org; Thu, 27 Oct 2005 22:39:55 -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 j9S2PgYr012946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Oct 2005 19:25:42 -0700
Received: (from daw@localhost) by taverner.CS.Berkeley.EDU (8.13.1/8.13.1/Submit) id j9S2Pgpn012942; Thu, 27 Oct 2005 19:25:42 -0700
From: David Wagner <daw@cs.berkeley.edu>
Message-Id: <200510280225.j9S2Pgpn012942@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:25:41 -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: 8b30eb7682a596edff707698f4a80f7d
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

Dan Bernstein writes:
>David Wagner writes:
>> The simplest randomized construction is to let UH(.,.) be a 2-universal
>> hash, pick R randomly, publish R, and use UH(R,S) as your key, where
>> S is the secret input.  This is a KDF with no auxiliary inputs.
>
>For example, if you have a 1024-bit Diffie-Hellman result with 512 bits
>of apparent entropy, and you want to convert it into a 256-bit key, you
>can view it as a polynomial mod 2, multiply by x^256, and reduce the
>result modulo a standard irreducible degree-256 polynomial.

I'd like to see the proof.  Can you show me how the proof goes?
I'll admit to a little bit of skepticism about its provable security.

Here's what's got me puzzled.  The Leftover Hash Lemma requires that
the 2-universal hash be chosen randomly.  You have specified a scheme
where we use a single hash function that has been fixed in advance --
but then the Leftover Hash Lemma is not applicable.  If you're not using
the Leftover Hash Lemma, then what are you using to prove this fact?
What are you assuming about Diffie-Hellman?

If you change your fixed hash function to a random 2-universal hash
function, then I'll believe your claim, albeit with a caveat that you
didn't mention.  The caveat is that your 256-bit key actually has only
128 bits of security, in the sense that the distribution on keys has
variation distance at most 1/2^128 from the uniform distribution.  Thus,
you have started out with 512 bits of entropy, and you've ended up with
only 128 bits of provable security.  That seems a little bit wasteful,
if I understand correctly.

I'd like to better understand the performance overhead of using
2-universal extractors.  We need 512 bits of apparent entropy in the
Diffie-Hellman shared secret g^{xy}.  It looks to me like this means
that we cannot use short exponent Diffie-Hellman: each party's exponents
need to be at least 512 bits long.  This sounds unfortunate, due to its
significant performance costs.  Do I have this correct?  Or is there
some trick that lets you prove this secure even with short exponents?

I'd welcome feedback about whether if my reasoning above is accurate....

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